fix: render chat stream deterministically via history versions - #27098
fix: render chat stream deterministically via history versions#27098ibetitsmike wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 441429bf07
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
441429b to
2f80d61
Compare
ffa5643 to
c6c329f
Compare
2f80d61 to
9300876
Compare
|
@codex review |
|
Codex Review: Didn't find any major issues. Chef's kiss. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
hugodutka
left a comment
There was a problem hiding this comment.
I'm not sure if this is the right thing to do. If we optimistically suppress the message parts after the user interrupts the chat, they'll reappear once the user reloads the page anyway, which would be confusing.
But even if we decide to suppress the parts, this approach doesn't feel robust. When I think about what message parts we should display to the user, I think in terms of the history_version that the frontend is aware of. After the user interrupts a chat that's on history_version n, then late message parts associated with version n should not be displayed to the user. But any message parts associated with versions > n should. This uses a heuristic instead: when the user interrupts, suppress message parts until the next non-interrupting status update comes over. I'd rather we relied on a method that considers history versions instead. While the heuristic would work most of the time, there are probably some edge cases it doesn't handle correctly.
5b1d8e8 to
dd3558a
Compare
Docs preview📖 View docs preview for |
|
I reworked this around the version model you suggested. I verified that interrupted output is persisted, so optimistic suppression only made content disappear and return after reload. I also found that status and The branch now exposes
|
|
@codex review |
dd3558a to
a6b7ec1
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a6b7ec1927
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
c6c329f to
cd12a50
Compare
a6b7ec1 to
53f61ec
Compare
|
@codex review |
|
Codex Review: Didn't find any major issues. What shall we delve into next? Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
53f61ec to
b86647e
Compare
|
@codex review |
|
Codex Review: Didn't find any major issues. 🚀 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
After internal discussions we'll be closing that one and aim at an RFC led cleanup of frontend rendering. |
Summary
Make live chat rendering match durable server state. Queued-message promotion no longer clears the stream, removes the queue row, or fabricates a
runningstatus while the server is interrupting the previous turn.Problem
Interrupted assistant output is persisted, so hiding live parts only made content disappear and return after reload. Status updates and
message_partevents also come from independent sources, which made status-based suppression racy.Fix
Expose
history_versionandgeneration_attempton chat and status payloads. The frontend uses that tuple and each part'sseqto replace the preview when a newer episode arrives and reject stale or replayed parts. Promotion keeps the authoritative queue row visible as a disabledPromoting...placeholder, and clears stale transient errors before starting the promoted request.Stacked on #27064.