Repository navigation
MAINT Extract ChatWindow send workflow into a reducer (#2652) - #4162
Open
Julio César Suástegui (juliosuas) wants to merge 6 commits into
Open
Julio César Suástegui (juliosuas) wants to merge 6 commits into
Julio César Suástegui (juliosuas) wants to merge 6 commits into
Conversation
Final step of microsoft#2652, after microsoft#3310 (loading), microsoft#3369 (score, objective and export) and microsoft#3812 (copy and branch). The send workflow's rendered state (per-conversation send and scoring locks, send issues, failed-send recoveries, repeated-send progress and the undoable last send) now moves through an explicit reducer with typed actions in utils/chatSendState.ts. useChatSendState owns that reducer plus the synchronous locks the conversation loader reads; useChatSend owns the commands: optimistic messages, attachment and conversion capture, lazy attack creation, progress tracking, refresh after unknown delivery and preparation-draft restore. Its input is grouped by seam (route, readiness, request, composer, loader, callbacks), and ChatWindow passes the conversation loader through unchanged. No prop, UI, accessibility, request payload or navigation changes. Reducer transitions and the hook's regression cases (duplicate sends, two conversations sending independently, optimistic prompts on return to an in-flight conversation, first-send conversation creation, unknown delivery, pre-submission failures, converted pieces) have focused tests. Refs microsoft#2652
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues were identified for the send-workflow extraction into a reducer and focused hooks.
No open issues 🎉
What changed in this PR
Continues #2652 by extracting ChatWindow’s send workflow into a reducer and focused hooks, building on the earlier loading, mutation/export, and copy/branch extractions.
Changes:
- Centralizes rendered send state in a typed reducer, including locks, recovery, repeated-send progress, and undo.
- Moves send orchestration into
useChatSendand synchronous tracking intouseChatSendState, leaving ChatWindow to compose them. - Adds focused reducer and hook tests for state transitions, independent sends, optimistic messages, recovery, and conversions.
| File | Description |
|---|---|
frontend/src/utils/chatSendState.ts |
Defines send state, actions, reducer, and recovery helpers. |
frontend/src/utils/chatSendState.test.ts |
Tests reducer transitions and persisted recovery handling. |
frontend/src/hooks/useChatSend.ts |
Owns send tracking, submission, progress, and recovery commands. |
frontend/src/hooks/useChatSend.test.ts |
Tests send orchestration and key failure paths. |
frontend/src/components/Chat/ChatWindow.tsx |
Replaces inline send orchestration with hook composition. |
Review effort: Balanced
Brings in microsoft#3663 (reload a sending conversation after another one has loaded) and microsoft#3772. The ChatWindow conflict is resolved by keeping the extracted send workflow; microsoft#3663's markConversationLoaded() on the created conversation moves to the first-send branch of useChatSend, where the created attack is now routed. Adds a useChatSend test for it.
Brings in microsoft#3506 (runtime generation configuration) and the rest of main since microsoft#3663. ChatWindow keeps the extracted send workflow; microsoft#3506's send path moves into useChatSend: - the request carries the composer's generation draft, snapshotted on the pending send and parsed against the target when the send starts; - the first piece carries request_generation_config instead of a temperature-rebuilt target binding (buildTemperatureTarget is gone, along with the now-unused targetResolutionStatus option); - a first send reports its created attack so ChatWindow keeps the next-send draft across that route change. ChatWindow keeps the draft state, generation settings UI and the send-disabled reason. useChatSend tests cover the request metadata, the send-time snapshot, the created-attack callback and out-of-range input.
# Conflicts: # frontend/src/components/Chat/ChatWindow.tsx
Adds a useChatSend test for a count > 1 send: one submission with the repeat options, sibling conversation adoption with its own lock and evidence read, lock release, and the repeat view surviving completion until dismissed. Documents dispatch/locksRef on ChatSendTracking as the seam driven by useChatSend only. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Roman Lutz (romanlutz)
approved these changes
Nov 13, 2026
Roman Lutz (romanlutz)
enabled auto-merge
November 13, 2026 08:59
This branch has not been deployed
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
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.
Description
Related to #2652. Final step: the send workflow as an explicit reducer plus the ChatWindow composition cleanup, as scoped in the issue thread. Loading landed in #3310, score/objective/export in #3369, and copy/branch in #3812.
frontend/src/utils/chatSendState.ts: reducer with typed actions for the send workflow's rendered state: per-conversation send and scoring locks, send issues, failed-send recoveries, repeated-send progress and the undoable last send.frontend/src/hooks/useChatSend.ts:useChatSendStateowns that reducer plus the synchronous locks the conversation loader reads;useChatSendowns the commands (optimistic messages, attachment and conversion capture, lazy attack creation, progress tracking, refresh after unknown delivery, preparation-draft restore). Its input is grouped by seam (tracking,route,readiness,request,composer,loader,callbacks) with typed, documented interfaces, followinguseConversationCopy.ChatWindow.tsx: composes the two hooks instead of inlining the send workflow (3,045 to 2,208 lines). The conversation loader result is passed through unchanged.No prop, UI, accessibility, request payload or navigation changes.
Open questions for review:
useChatSendcan consume the loader. Is that boundary acceptable, or would you prefer a different split?Tests and Documentation
chatSendState.test.ts(reducer transitions) anduseChatSend.test.ts(duplicate sends, two conversations sending independently, optimistic prompts on return to an in-flight conversation, first-send conversation creation, unknown delivery, pre-submission failures, converted pieces): 31/31.tsc --noEmit: 0 errors. Lint: 0 errors.npm run buildpasses.e2e/onboarding-tour.spec.tsfail identically on main (935afa8).AI-assisted; reviewed and tested by me.