Repository navigation
prompt_async returns 204 before prompt persistence completes #38092
Description
Description
The prompt_async handler forks the entire prompt operation, including user-message persistence, and immediately returns HTTP 204. A client can therefore observe a successful response before the prompt has been durably admitted. If the process or request scope ends in that window, the caller has no way to distinguish an accepted prompt from one that never reached storage.
Expected behavior
HTTP 204 should mean the user message has been persisted. Model execution can remain asynchronous.
Suggested change
Separate prompt admission from loop execution: await admission in the handler, then fork only the session loop when noReply is not set. A regression test can call promptAsync with noReply: true and immediately verify the message is present.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Jul 21, 2026
This issue might be a duplicate of existing issues. Please check:
prompt_asyncreturns 204 after startup failure, leaving empty child sessions — covers overlapping territory around the 204-before-durable-state contract; the root cause and scope differ but the proposed fix direction aligns closelypromptAsyncmessage persisted but session loop never scheduled — a related async-prompt lifecycle gap where persistence succeeds but execution is silently droppedgithub-actions commentedon Sep 20, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.