Summary

Adds characterization tests and benchmarks for PersistenceObserver streaming persistence — the path that mirrors assistant token deltas (AgentChoice / AgentChoiceReasoning) into a single growing message row in the session store.

This establishes a baseline before any future optimization (e.g. debounced flushes) and documents the per-chunk store write contract that the observer currently implements.

Context

During a streaming assistant turn, the runtime emits one AgentChoiceEvent per delta. PersistenceObserver.persistStreamingContent keeps a single in-flight row and:

1. INSERT (AddMessage) on the first chunk
2. UPDATE (UpdateMessage) on every subsequent chunk
3. UPDATE again on MessageAddedEvent to finalise the row with the canonical payload

This behaviour is easy to regress when refactoring persistence or the store layer, but was not previously covered by a focused unit test or benchmark.

Changes

New file: pkg/runtime/persistence_observer_bench_test.go

Tests

Both tests use a countingStore wrapper around InMemorySessionStore to assert store call counts without mocking the observer.

Benchmarks

Each iteration simulates a long assistant turn: 500 AgentChoice deltas + 1 MessageAdded finalisation (streamingBenchChunks = 500).

Sample results (darwin/arm64, Apple M3 Pro)

BenchmarkPersistenceObserver_StreamingChunks-12          ~2.0 ms/op    502 KB/op    2515 allocs/op
BenchmarkPersistenceObserver_StreamingChunks_SQLite-12   ~3.1 ms/op   1558 KB/op    8714 allocs/op

Per chunk (500 chunks/iter): ~4 µs in-memory, ~6 µs SQLite, ~5 vs ~17 allocs.

SQLite is ~1.5× slower and ~3× more alloc-heavy — expected given JSON marshal + SQL per update.

Known benchmark caveats

• In-memory drift: the in-memory benchmark reuses the same session across b.N iterations, so UpdateMessage eventually scans an ever-growing message list (O(messages) per update). Later iterations are slower than the first. SQLite stays flat because updates are keyed by message_id.
• Migration logs: SQLite setup calls NewSQLiteSessionStoreFromDB, which logs migration info before b.ResetTimer() — noisy stdout but not included in ns/op.

These caveats are acceptable for a baseline but worth keeping in mind when comparing future numbers.

Why now?

Streaming persistence is on the hot path for every assistant response when a session store is configured. Having explicit tests + benchmarks makes it safer to:

• change the flush strategy (per-chunk vs debounced)
• optimize persistStreamingContent (avoid strings.Builder.String() copies on every delta)
• compare in-memory vs SQLite store performance under realistic chunk counts

Test plan

• go test ./pkg/runtime -run TestPersistenceObserver_UpdateCountPerChunk -v
• go test ./pkg/runtime -run TestPersistenceObserver_StreamingContentAccumulates -v
• go test ./pkg/runtime -run=^$ -bench=BenchmarkPersistenceObserver -benchmem -count=1
• task test (full suite)
• task lint