Before submitting
Area
apps/web
Summary
When a thread has hasPendingUserInput (sidebar status input), the composer shows an enabled Submit / Submit answer(s) button, but clicking it (or Enter) silently does nothing. The button enabled-state and the submit path check different preconditions.
Button enabled (apps/web/src/components/chat/ComposerPrimaryActions.tsx:147-151) only checks:
disabled={isEnvironmentUnavailable || pendingAction.isResponding || (isLast ? !isComplete : !canAdvance)}
But the submit path blocks on normal-send preconditions the button ignores:
apps/web/src/components/chat/ChatComposer.tsx:1890 — submitComposer early-returns on noProviderAvailable || isSendDisabled (e.g. threadDetailLoading → Messages loading, image-compression guard), before reaching the pending-user-input dispatch at :1907-1918.
apps/web/src/components/ChatView.tsx:5037-5064 — onSend checks !activeThread || isSendBusy || isConnecting || threadDetailLoading || sendInFlightRef.current and returns silently, before the if (activePendingProgress) onAdvanceActivePendingUserInput() branch at :5057. No toast, no threadError.
A pending-user-input answer is a lightweight thread.user-input.respond command — it needs no provider, no send context, no images. Gating it behind provider-turn sendability strands the user on the Input badge with an enabled button that drops the click.
Distinct from #5454 (server-side No active provider session stuck after restart, which also needs its fix). This is client-side and reproduces with a live session.
Steps to reproduce
- Get an agent to call
request_user_input / AskUserQuestion so the pending-user-input card + Submit renders.
- Put the composer in any normal-send-blocked state while the card is open, e.g. thread detail loading, reconnecting (
isConnecting), a send in flight (sendInFlightRef / isSendBusy), or no provider selected (noProviderAvailable).
- Answer the question so Submit is enabled (isComplete/canAdvance true) and click Submit / press Enter.
- Nothing happens: no dispatch, no toast, no error. Button just sits there.
Code proof: enabled Submit → form onSubmit={submitComposer} (ChatComposer.tsx:2818) → early return at :1890-1893 → preventDefault + return. Or if it reaches onSend, early return at ChatView.tsx:5037-5046 before :5057.
Expected behavior
An enabled pending-user-input Submit always dispatches onAdvanceActivePendingUserInput → thread.user-input.respond. Normal-send guards (isSendBusy/isConnecting/threadDetailLoading/sendInFlight/noProviderAvailable/isSendDisabled) must not block the pending path; only !activeThread and environment-unavailable should.
Actual behavior
Enabled Submit is swallowed silently by those guards. Zero feedback.
Impact
Major degradation or frequent failure
Before submitting
Area
apps/web
Summary
When a thread has
hasPendingUserInput(sidebar statusinput), the composer shows an enabled Submit / Submit answer(s) button, but clicking it (or Enter) silently does nothing. The button enabled-state and the submit path check different preconditions.Button enabled (
apps/web/src/components/chat/ComposerPrimaryActions.tsx:147-151) only checks:But the submit path blocks on normal-send preconditions the button ignores:
apps/web/src/components/chat/ChatComposer.tsx:1890—submitComposerearly-returns onnoProviderAvailable || isSendDisabled(e.g.threadDetailLoading → Messages loading, image-compression guard), before reaching thepending-user-inputdispatch at :1907-1918.apps/web/src/components/ChatView.tsx:5037-5064—onSendchecks!activeThread || isSendBusy || isConnecting || threadDetailLoading || sendInFlightRef.currentand returns silently, before theif (activePendingProgress) onAdvanceActivePendingUserInput()branch at :5057. No toast, no threadError.A pending-user-input answer is a lightweight
thread.user-input.respondcommand — it needs no provider, no send context, no images. Gating it behind provider-turn sendability strands the user on the Input badge with an enabled button that drops the click.Distinct from #5454 (server-side No active provider session stuck after restart, which also needs its fix). This is client-side and reproduces with a live session.
Steps to reproduce
request_user_input/ AskUserQuestion so the pending-user-input card + Submit renders.isConnecting), a send in flight (sendInFlightRef/isSendBusy), or no provider selected (noProviderAvailable).Code proof: enabled Submit → form
onSubmit={submitComposer}(ChatComposer.tsx:2818) → early return at :1890-1893 →preventDefault+ return. Or if it reachesonSend, early return atChatView.tsx:5037-5046before :5057.Expected behavior
An enabled pending-user-input Submit always dispatches
onAdvanceActivePendingUserInput→thread.user-input.respond. Normal-send guards (isSendBusy/isConnecting/threadDetailLoading/sendInFlight/noProviderAvailable/isSendDisabled) must not block the pending path; only!activeThreadand environment-unavailable should.Actual behavior
Enabled Submit is swallowed silently by those guards. Zero feedback.
Impact
Major degradation or frequent failure