Skip to content

Full and recent reads

For the complete documentation index see: llms.txt

All documentation pages available in markdown.

On the previous page, you appended 20,000 events to one ADK session, spread across many segment records. The same script then runs a read phase automatically.

Keep the terminal open if infinite-chat-history-demo.py is still running from the previous page.

Review the read phase output

  1. Find the read section in your terminal output:

    After append_event x20000, the script calls get_session three ways on the same session:

    infinite-chat-history-demo.py
    full = await session_service.get_session(
        app_name=APP, user_id=USER, session_id=SID
    )
    print(f"full history: {len(full.events)} events")
    

    recent5 = await session_service.get_session(
        app_name=APP, user_id=USER, session_id=SID,
        config=GetSessionConfig(num_recent_events=5),
    )
    print(f"num_recent_events=5: {texts5}")
    

    after = await session_service.get_session(
        app_name=APP, user_id=USER, session_id=SID,
        config=GetSessionConfig(after_timestamp=t0 + 19_990 * 0.001),
    )
    print(f"after_timestamp (last ~10 turns): {len(after.events)} events")
    full history: 20000 events
      first: turn 0 from user: context line for a long-running agent session.
      last:  turn 19999 from assistant: context line for a long-running agent session.
      merged state keys: ['app:tenant', 'user:locale', 'step']
    num_recent_events=5: ['turn 19995 from assistant: context line for a long-running agent session. ', 'turn 19996 from user: context line for a long-running agent session. ', 'turn 19997 from assistant: context line for a long-running agent session. ', 'turn 19998 from user: context line for a long-running agent session. ', 'turn 19999 from assistant: context line for a long-running agent session. ']
    after_timestamp (last ~10 turns): 10 events

  2. Confirm the read results:

    Twenty thousand events now span many segment records. The demo called get_session three ways on the same session without appending anything else.

    • full history: 20000 events with correct first and last turn text.
    • Its merged state includes app:tenant, step, and user:locale from the three state scopes.
    • num_recent_events=5 returns five recent event texts without loading the full history.
    • after_timestamp returns about 10 events for the last turns.

Why partial reads matter

The demo called get_session without a config to prove all 20,000 events are stored and ordered correctly. That full read walks every segment record.

For a running agent, you rarely need the full transcript on every turn. GetSessionConfig limits what Aerospike returns:

Read modeWhat you ask for
No configAll 20,000 events
num_recent_events=5Last 5 turns
num_recent_events=50Last 50 turns
num_recent_events=100Last 100 turns
num_recent_events=500Last 500 turns
after_timestampEvents after a cutoff (demo: ~10 for the last turns)

Fetch cost grows with how many events you return, not with total session length. A session can hold millions of turns. Fetching the last five for model context stays fast because Aerospike reads only the relevant segment tail.

In production: use num_recent_events when you only need recent turns for the LLM context window. Use after_timestamp when you need everything after a known point (for example, resuming mid-conversation). Use a full get_session read when the UI needs the complete transcript, or for export and debugging.

On the next page, you inspect how those 20,000 events are distributed across segment records.