fix(channels): emit poll bursts in chronological order across sidecar adapters#5305
Merged
Conversation
… adapters Rocket.Chat (channels.history), Mastodon (/api/v1/notifications), Reddit (?sort=new), and Bluesky (listNotifications) all poll upstreams that return newest-first, but each iterated the raw response and emitted in that order. So a single poll catching more than one new message delivered them to the agent in reverse chronological order. Reverse each batch to oldest-first before emitting, matching the chronological order nextcloud's Talk feed already yields. Dedupe sets and per-room / since high-water marks are order-independent, so this only changes delivery order. Faithfully reproduced from the original in-process Rust adapters; surfaced while reviewing the rocketchat sidecar migration (#5298). Tests: test_poll_once_emits_in_chronological_order added to each adapter's suite; existing fixtures that hand-ordered input ascending updated to the realistic newest-first shape. 478 Python tests pass.
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
1 participant
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.
Summary
Surfaced while reviewing the Rocket.Chat sidecar migration (#5298): four
polling sidecar adapters delivered multi-message poll bursts to the agent
in reverse chronological order.
rocketchat(channels.history),mastodon(/api/v1/notifications),reddit(?sort=new), andbluesky(listNotifications) all pollupstreams that return newest-first, but each iterated the raw response
and emitted in that order. When a single poll caught more than one new
message, the agent received them backwards — wrong for conversation
context.
nextcloud(the closest sibling) is unaffected because Talk'schat feed already returns oldest-first.
The bug was faithfully reproduced from the original in-process Rust
adapters, so each migration carried it forward.
Fix
Reverse each batch to oldest-first before emitting:
rocketchat.py—for msg in reversed(messages)in_poll_oncemastodon.py—for notif in reversed(notifs)in_poll_oncereddit.py—for child in reversed(children)in_poll_oncebluesky.py—for notif in reversed(notifs)in_poll_onceDedupe sets and the per-room /
since_id/ max-indexedAthigh-watermarks are all order-independent, so this changes delivery order only —
no impact on watermark advancement or duplicate suppression.
Tests
test_poll_once_emits_in_chronological_orderto each of the fouradapter suites: feeds a realistic newest-first batch, asserts oldest →
newest emit, and (where applicable) asserts the high-water mark still
tracks the newest item regardless of emit order.
the bug) to the realistic newest-first shape:
test_poll_once_emits_messages_and_advances_watermark(rocketchat),test_poll_once_emits_parsed_comments(reddit).test_poll_once_dedupes_same_ts_repeats(rocketchat) assertion madeorder-insensitive since it covers dedupe, not ordering.
Verification
No Rust changed (Python SDK only);
cargo clippy --workspaceran clean viathe pre-push hook.
Out-of-scope (flagged, not changed here)
CHANGELOG.mdonmainalready has two## [Unreleased]sections(line 8 and ~1105) — a pre-existing structural issue (the pre-commit guard
warns release tooling silently drops entries from all but the first). It
predates this branch and would require merging hundreds of lines of
unrelated entries, so I left it alone and omitted a CHANGELOG entry for
this fix rather than reorganize others' notes. Worth a dedicated cleanup.