fix(cloud-agent-next): stabilize queue e2e scenarios after #6660 - #6726
Merged
Merged
Conversation
#6660 dispatches queued follow-ups to a ready runtime without waiting for the running turn, so the pending queue drains between sequential sends and batched follow-ups settle through concurrent per-message deliveries. queue-overflow now fills the pending queue with bounded concurrent waves so the server-enforced 429 is reliably reached. queue-while-busy and queue-rapid-fire-no-gate now wait for every expected terminal and assert FIFO on cloud.message.sent (in-order delivery) instead of requiring completion frames to arrive in order. Adds regression unit tests; both fail on the previous implementation.
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
Contributor
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Executive SummaryThe incremental change at Files Reviewed (1 file)
Previous Review Summaries (2 snapshots, latest commit 408500a)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 408500a)Status: 1 Issue Found | Recommendation: Address before merge Executive SummaryThe two prior suggestions were verified fixed at Overview
Issue Details (click to expand)SUGGESTION
Files Reviewed (1 file)
Fix these issues in Kilo Cloud Previous review (commit 65b38df)Status: 2 Issues Found | Recommendation: Address before merge Executive SummaryTest-only stabilization PR; both findings are low-severity diagnostic gaps in the new bounded concurrent fill loop of Overview
Issue Details (click to expand)SUGGESTION
Files Reviewed (2 files)
Reviewed by deepseek-v4.1-flash · Input: 0 · Output: 0 · Cached: 0 Review guidance: REVIEW.md from base branch |
Report the failing attempt index (not the post-wave counter) and stop scanning a wave once a within-budget 429 is found, so a later after-budget rejection cannot overwrite the success message while ok is true.
Finish scanning each wave after a rejection so every admitted message enters queuedIds and the failed-event barrier waits for it. Guard the success assignment with overflowOk so a later after-budget rejection cannot overwrite the message.
chrarnoldus
approved these changes
Sep 28, 2026
This was referenced Sep 27, 2026
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
2 participants
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
Fix flakiness in the deployed e2e queue scenarios introduced by the delivery semantics of #6660.
headQueuedMessageIdnow returns the oldest queued id even while another message is accepted, so a ready runtime receives queued follow-ups without waiting for the running turn. Two scenarios assumed the previous semantics:queue-overflow: sent fills sequentially, so the DO drained the pending queue between sends and the 10-message limit was often never reached — no 429.queue-while-busy: snapshotted the event buffer at the third message's terminal and required all three completion frames to already be present. fix(cloud-agent-next): deliver follow-ups without waiting for the current turn #6660 settles batched follow-ups through concurrent per-message deliveries, so completion frames can arrive out of order or late.Changes (test-only,
services/cloud-agent-next/test/e2e/scenarios-shared-queue.ts):queue-overflowfills the pending queue with bounded concurrent waves. Admissions are serialized inside the DO, so a burst closes the capacity window before delivery can drain it, and the server-enforced 429 is reliably reached.queue-while-busyandqueue-rapid-fire-no-gatewait for every expected message terminal, then assert all completed and FIFO oncloud.message.sent. In-order delivery is the documented contract (SESSION-CONTINUITY.mdE2, e2e README); completion-frame arrival order is not.Adds regression unit tests in
scenarios-shared.test.ts; both fail on the previous implementation.Verification
pnpm dev:start cloud-agent, worktree offset 1000):queue-overflow4/4 runs reachTOO_MANY_REQUESTS: Pending message queue is full (10), cleanup cleared;queue-while-busy2/2;queue-rapid-fire-no-gate1/1;queue-interrupt-clears1/1.pnpm --filter cloud-agent-next typecheck,lint, and the full unit suite (7665 passed, 3 skipped).Visual Changes
N/A
Reviewer Notes
cloud-agent-e2e-tests.yml.E2E_PARALLEL: 4), so the mechanism is inferred from fix(cloud-agent-next): deliver follow-ups without waiting for the current turn #6660, the queue integration test, and the failure signatures rather than a measured before/after flake rate.cloud.message.sent). If reviewers consider serial completion a contract, the wrapper's concurrent per-message settlement is the place to enforce it.