fix(queue): preserve queued platform message ids in collect drains (Fixes #36212)#91272
fix(queue): preserve queued platform message ids in collect drains (Fixes #36212)#91272deepujain wants to merge 1 commit into
Conversation
Keep the latest queued platform message id when collect-mode followups synthesize a combined deferred turn. Fixes openclaw#36212
|
Focused fix for the collect/overflow queue drain path. I validated the new regression in |
|
Codex review: needs real behavior proof before merge. Reviewed June 7, 2026, 8:15 PM ET / 00:15 UTC. Summary PR surface: Source +23, Tests +44. Total +67 across 2 files. Reproducibility: yes. Source inspection gives a high-confidence path: enqueue same-route collect-mode FollowupRun items with messageId values, then drain; current main synthesizes the collected run without carrying messageId forward. Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land this focused queue-layer preservation only after redacted real behavior proof or maintainer-run channel proof confirms the collected queued turn can use the preserved platform message id. Do we have a high-confidence way to reproduce the issue? Yes. Source inspection gives a high-confidence path: enqueue same-route collect-mode FollowupRun items with messageId values, then drain; current main synthesizes the collected run without carrying messageId forward. Is this the best way to solve the issue? Yes. The queue drain is the owner boundary where collected followup runs are synthesized, so preserving the already-stored message metadata there is narrower and cleaner than a Feishu-only workaround. AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 5c5391836b1e. Label changesLabel justifications:
Evidence reviewedPR surface: Source +23, Tests +44. Total +67 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
Summary
Fixes #36212.
Collected queued followups were dropping the original platform
message_idwhen the drain synthesized a combined[Queued messages while agent was busy]turn. The queue already stores each inbound platform message id, but the collect and overflow-summary drain paths were rebuilding a new followup run without carrying that metadata forward.This change keeps the latest queued item's
messageId(and reply-target id when present) on the synthesized followup run so downstream message tooling can still target the real platform message instead of a synthetic placeholder id.Non-goals:
Tests and validation
node scripts/run-vitest.mjs src/auto-reply/reply/queue.collect.test.ts node scripts/run-vitest.mjs src/auto-reply/reply/followup-runner.test.ts --testNamePattern "restart sentinel routed followups use reply target ids for CLI current message context" git diff --checkReal behavior proof
Behavior addressed:
message_idwhen they collapse multiple queued inbound messages into a single deferred turnEnvironment tested:
main-based branchEvidence after the fix:
src/auto-reply/reply/queue.collect.test.tsthat enqueues two Feishu-style queued messages with distinctmessageIdvalues and verifies the drained collected followup keepsplatform-msg-2Observed result:
What was not tested:
im.message.replycall against a real channel accountProof limitations:
Risk
Low. This only changes metadata preservation on synthesized queued followup runs. It does not alter queue admission, batching rules, or provider routing. The main behavior change is that downstream tooling sees the real latest queued platform message id where previously it saw no preserved queued message id.