LibreChat-AI#16632 drains a follow-up queued in a chat the user left by resolving the detached run's end from persisted history on return. History cannot express every case, and the maintainer chose to keep that approach and defer the rest to a server-recorded outcome.
Finding: LibreChat-AI#16632 (comment)
Not covered today:
- Leaving after the generation POST reached the server but before its response resolved: the pane has no stream and no generation epoch, so nothing is recorded and the follow-up stays queued for a manual send.
- A detached regeneration: history still holds the reply it rewrites, so it is left for a manual send.
- A detached run with no captured epoch whose queue the server shares (admission receipts or server-owned rows): left for a manual send.
Proposed design: when a generation job reaches a terminal state, record { createdAt, status, userMessageId, responseMessageId } for the conversation under a short TTL (the same bounded-TTL pattern the server already uses for parked steers), and return it from the jobless /chat/status response. The client then parks an exact run end (epoch, true outcome, response id) instead of inferring it from history, and the history inference, the regeneration guard and the stop-request flag in useResumableSSE can go. Behavior belongs in packages/api (job manager), with the status route only forwarding the field.
LibreChat-AI#16632 drains a follow-up queued in a chat the user left by resolving the detached run's end from persisted history on return. History cannot express every case, and the maintainer chose to keep that approach and defer the rest to a server-recorded outcome.
Finding: LibreChat-AI#16632 (comment)
Not covered today:
Proposed design: when a generation job reaches a terminal state, record
{ createdAt, status, userMessageId, responseMessageId }for the conversation under a short TTL (the same bounded-TTL pattern the server already uses for parked steers), and return it from the jobless/chat/statusresponse. The client then parks an exact run end (epoch, true outcome, response id) instead of inferring it from history, and the history inference, the regeneration guard and the stop-request flag inuseResumableSSEcan go. Behavior belongs inpackages/api(job manager), with the status route only forwarding the field.