Configure TTL, start, and resume

For the complete documentation index see: llms.txt

All documentation pages available in markdown.

The cookbook wires a chat graph in agent.py and runs the TTL lifecycle in demo.py. Open those files if you want to see how messages are constructed and how each invoke writes a checkpoint through AerospikeSaver.

Run the demo (—skip-wait)

From the repository root, run the demo with --skip-wait (Phases 1 through 3, without the TTL wait):
Terminal window
```
uv run python cookbooks/expiring-chat-sessions/demo.py --skip-wait
```

Review Phases 1 and 2:

Watch checkpoint TTL at the end of Phase 2. It should read 60 seconds, confirming the TTL landed on the Aerospike record, not just in the saver config.

================================================================
Phase 1 - Configure TTL
================================================================
  namespace        : test
  thread_id        : session-demo-001
  default_ttl      : 1 minute(s)
  refresh_on_read  : False
  -> Every checkpoint write is stamped with this TTL by Aerospike.

================================================================
Phase 2 - Start a chat session
================================================================
  user      > Hello, I need help with my order.
  assistant > Hi! I'm your support assistant. How can I help?
  messages stored  : 2
  checkpoint TTL   : 60 seconds (set natively by Aerospike)

Confirm Phase 1 and Phase 2:

Phase 1 constructed AerospikeSaver with a one-minute default TTL and refresh_on_read=False. From this point forward, every checkpoint write for session-demo-001 is stamped at the Aerospike record layer, not in application memory.

Phase 2 sent the first user message through the chat graph. LangGraph wrote a checkpoint containing the user message and assistant reply. The demo then read TTL from the Aerospike record metadata to confirm the stamp landed on storage, not just in the saver config.
- messages stored is 2 after the first turn (one user message, one assistant reply).
- checkpoint TTL reports 60 seconds, matching the one-minute default.

Review Phase 3 in the same output:

Watch messages stored. It should read 4, confirming the prior two messages were loaded from the checkpoint rather than starting a fresh session.

================================================================
Phase 3 - Resume the same thread
================================================================
  user      > Are you still tracking my conversation?
  assistant > Got it -- I've noted that down for this session.
  messages stored  : 4  (history preserved across the resume)

================================================================
Done (--skip-wait)
================================================================
  Skipped the TTL wait. Re-run without --skip-wait to watch it expire.

Confirm the resume loaded prior history:

Phase 2 stored two messages for thread_id=session-demo-001 and stamped the checkpoint with a one-minute TTL. Phase 3 tests whether that state is still there: the demo sends a second user message on the same thread while the TTL has not elapsed.

AerospikeSaver loaded the Phase 2 checkpoint from Aerospike, appended the new user message and assistant reply, and wrote an updated checkpoint. No new session was created.
- messages stored increased from 2 to 4 (two prior messages plus the new user/assistant pair).
- The assistant reply is the second scripted line from FakeListChatModel. That response only appears when prior messages were loaded from Aerospike, not on a fresh thread.
History stays on this thread_id until the TTL expires. Prove expiry runs the full demo without --skip-wait to show Aerospike reclaiming the records. This demo leaves refresh_on_read as False. When enabled, reads can reset the TTL window on each access.