Summary
FileHistoryProvider.save_messages() applies filter_new_messages() for the default JSONL format, but the opt-in MessagePack branch appends every supplied message without the same replay protection.
This makes the two supported serialization formats behave differently when a client sends a complete transcript on every turn. It appears to be a follow-up gap in #7242: that deduplication change covered the FileHistoryProvider JSON path but not the MessagePack path.
Reproduction
On upstream main at commit 018056a52, using a real Agent / AgentSession lifecycle with a fixed session, I passed the complete transcript back to the agent for ten turns. Each response was unique.
| input pattern |
JSONL |
MessagePack |
| 10 turns, full transcript replay |
20 records / 3,000 bytes |
110 records / 13,530 bytes |
The same behavior reproduces directly through FileHistoryProvider.save_messages():
| input pattern |
JSONL |
MessagePack |
| 10 cumulative transcript writes |
20 records / 2,840 bytes |
110 records / 12,870 bytes |
With delta-only input, both formats store 20 records. No exception is raised; loading the session instead returns repeated turns, increasing disk usage and later history/model-context size.
Expected behavior
MessagePack should have the same append semantics as JSONL: append only messages new relative to existing history, preserve order and legitimate duplicates within one incoming batch, and retain compatibility with existing length-prefixed records.
I intend to implement this as a focused follow-up to #7242 by applying the existing deduplication logic to MessagePack writes and adding format-parametrized regression tests.
This is limited to FileHistoryProvider persistence. It does not duplicate the open AG-UI context-composition work in #8135 or snapshot-resume work in #8149.
Summary
FileHistoryProvider.save_messages()appliesfilter_new_messages()for the default JSONL format, but the opt-in MessagePack branch appends every supplied message without the same replay protection.This makes the two supported serialization formats behave differently when a client sends a complete transcript on every turn. It appears to be a follow-up gap in #7242: that deduplication change covered the FileHistoryProvider JSON path but not the MessagePack path.
Reproduction
On upstream main at commit
018056a52, using a real Agent / AgentSession lifecycle with a fixed session, I passed the complete transcript back to the agent for ten turns. Each response was unique.The same behavior reproduces directly through FileHistoryProvider.save_messages():
With delta-only input, both formats store 20 records. No exception is raised; loading the session instead returns repeated turns, increasing disk usage and later history/model-context size.
Expected behavior
MessagePack should have the same append semantics as JSONL: append only messages new relative to existing history, preserve order and legitimate duplicates within one incoming batch, and retain compatibility with existing length-prefixed records.
I intend to implement this as a focused follow-up to #7242 by applying the existing deduplication logic to MessagePack writes and adding format-parametrized regression tests.
This is limited to FileHistoryProvider persistence. It does not duplicate the open AG-UI context-composition work in #8135 or snapshot-resume work in #8149.