Conversation
|
This PR doesn't fully meet our contributing guidelines and PR template. What needs to be fixed:
Please edit this PR description to address the above within 2 hours, or it will be automatically closed. If you believe this was flagged incorrectly, please let a maintainer know. |
|
Hey! Your PR title Please update it to start with one of:
Where See CONTRIBUTING.md for details. |
|
The following comment was made by an LLM, it may be inaccurate: Based on my search results, I found one potentially related PR: Related PR:
This PR (21473) appears to fix the underlying root cause (serializing session updates to prevent race conditions), while PR #17149 specifically addresses ordering messages by creation time on the web side. They are complementary fixes for message ordering issues. No other duplicate PRs found that directly address the same issue. |
e2ae9b3 to
b2ea09a
Compare
All ACP sessionUpdate calls are now routed through a promise chain (`sendUpdate`) that guarantees ordering. After each prompt completes, a reconciliation step fetches the final assistant message and delivers any text/reasoning content that was missed by SSE delta events — fixing a race where streaming events arrive after end_turn. Also adds handling for the `question.asked` event via the ACP permission flow, and updates the question tool to use a two-step async pattern.
b2ea09a to
bd8ba18
Compare
|
This pull request has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window. Feel free to open a new pull request that follows our guidelines. |
Issue for this PR
Closes #21314
Type of change
What does this PR do?
This PR fixes an issue where session updates could be applied out of order, leading to incorrectly ordered messages.
The root cause was that session updates were processed concurrently, so their execution order was not guaranteed. As a result, message ordering could become inconsistent depending on timing.
This change serializes session updates to ensure they are processed in a strict sequence. By enforcing ordered execution, message order is now deterministic and consistent, avoiding race conditions without introducing significant overhead.
How did you verify your code works?
Screenshots / recordings
N/A
Checklist