Repository navigation
fix(agent): keep new turns when the session transcript hits its byte cap - #138
Draft
cursor[bot] wants to merge 1 commit into
Draft
cursor[bot] wants to merge 1 commit into
cursor[bot] wants to merge 1 commit into
Conversation
Compaction runs only after max_context_messages, so a few long replies filled the 128 KiB JSON cap and the save was refused. Later turns were dropped while the old transcript stayed in place. Evict the oldest messages until this exchange fits, and still refuse a truncated JSON write. Co-authored-by: esadrianno <esadrianno@gmail.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug and impact
A session whose JSON is near the 128 KiB transcript cap, but whose message count is still under
max_context_messages(default 40), never compacts. The next successful turn prints a document over the cap,copy_printed_session_jsonrefuses the truncated write, andsession_saveis skipped. The reply is delivered, then every later turn is forgotten while the old transcript stays in place.Concrete trigger: two stored messages of about 62 KiB each (count 2, under the compaction threshold) and one more assistant reply of 16 KiB. WebChat can hit the same cap in normal use: each turn can store up to 32 KiB of user text plus 32 KiB of assistant text, so a handful of long replies fills 128 KiB long before 40 messages.
Root cause
Compaction is count-based (
msg_count > max_context_messages). The byte cap is enforced only by refusing the save, which was the right guard against persisting clipped JSON, but it left the row stuck at the old size.Fix
append_exchange_to_session_jsondrops the oldest messages until the new exchange fits, then writes valid JSON. If the newest messages alone still do not fit, the save is still refused and the stored row is left unchanged.Validation
make test_agentpassed. The overflow regression now requires the new user text to be stored, the older retained turn to remain, and the evicted oldest turn to be gone. The separate case of a blob already larger than the load cap still skips persist and does not wipe the row.