UI message can get stuck when backend error is not correlated to a request or session

[kc-zero-lab]

Problem

A UI chat/message can remain stuck in a loading/sending state when an error is emitted without being attached to a specific requestId or sessionId.

Because the error is unscoped, the UI cannot reliably determine which pending request/session should be failed, cleared, or annotated. The user sees a message that appears to be stuck rather than a concrete error on the relevant request.

Expected behavior

• Every request lifecycle error that can affect a UI message should include enough correlation metadata to target it, at minimum the relevant requestId and/or sessionId.
• The UI should attach the error to the matching pending message/session and transition it out of the loading state.
• If correlation metadata is genuinely unavailable, the UI should surface a safe global/session-level error and avoid leaving any pending message indefinitely stuck.

Suggested fix / investigation

• Audit request/session error paths for missing requestId / sessionId propagation.
• Ensure emitted error events preserve correlation fields from the originating request.
• Add a defensive UI fallback/timeout so uncorrelated errors do not leave messages permanently pending.
• Add regression coverage for an error event without correlation metadata.

Notes

Reported from product discussion: “the UI message gets stuck; the error isn’t being attached to a specific request id or session id.”