fix(compression): recover rotated session lineage - #70121
Conversation
d911515 to
279f023
Compare
Related: #64373 hardens durable lease/atomic rotation. This PR additionally repairs stale-worker session adoption and gateway transcript rerouting after a rotation; reviewers should assess the complementary recovery path. |
|
too large to review safely This PR changes 583 production lines before tests and docs. Please split it or add a focused justification if it should stay together. Signed: GPT-5.6-terra-low in Codex |
|
Merged via #71001 with your authorship preserved — atomic child publication, closed-parent write guard, and live-child adoption all shipped. Follow-ups: publish_compression_child now inherits profile/thread/display/origin from the parent (the direct INSERT would have bypassed fork inheritance), and the pre-lease drift guard became rotation-only + length-based (content equality aborted in-place compaction and would wedge on legal in-memory mutation). Thanks for tackling the hardest subsystem in the sweep. |
Summary
Problem
A gateway or WebUI worker can remain bound to the parent session after another compression path has already rotated it. The existing duplicate-rotation guard correctly skips a second rotation, but the stale worker can then continue appending messages to the closed parent. Repeated turns grow the obsolete transcript until the provider context limit is reached.
Approach
end_reason=compressionValidation
origin/main: 82 passedgit diff --check origin/main...HEADpassedOperational evidence
The regression was reproduced from a parent session closed by compression that subsequently received hundreds of messages while its canonical child remained live. The fix is generic and contains no site-specific configuration or credentials.