You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Submit button in Input status does nothing — enabled pending-user-input Submit is swallowed by normal-send guards #9318
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
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:
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.
Existing fix: #22874, branch fix/issue-9318-pending-input-submit, explicitly covers this report. Its diff routes pending answers around provider-turn send guards. Current main is ed9b7ca9c5. No duplicate PR opened. No runtime reproduction performed in this triage; the existing PR also reports no running-app click verification. Leaving this issue open until the fix lands.
Activity
juliusmarminge commentedon Oct 22, 2026
Existing fix: #22874, branch
fix/issue-9318-pending-input-submit, explicitly covers this report. Its diff routes pending answers around provider-turn send guards. Current main is ed9b7ca9c5. No duplicate PR opened. No runtime reproduction performed in this triage; the existing PR also reports no running-app click verification. Leaving this issue open until the fix lands.