fix: Genie plugin — handle in-progress messages on reload and fix message overflow

[calvarjorge]

Summary

• Bug fix: in-progress messages on page reload — When reloading a page while a Genie message is still loading, the history endpoint returned the in-progress message which the frontend silently dropped (no attachments yet), leaving the UI broken with no way to recover. Added a new single-message polling endpoint (GET /:alias/conversations/:conversationId/messages/:messageId) that SSE-streams status updates until the message completes. The frontend now detects pending messages after history load and polls via this endpoint, reusing the existing processStreamEvent pipeline.

• Bug fix: message bubbles overflowing the chat viewport — Response bubbles extended past the visible area.

Before

After

[pkosiec]

LGTM, works well

[pkosiec]

we have duplication in two files for those statuses

[pkosiec]

Here are some P2 stuff from agentic review:

1. hasAttachments guard causes FAILED messages to leave a phantom placeholder
  use-genie-chat.ts:236 — In processStreamEvent, the condition last.id === "" && hasAttachments means if the API returns a message_result for a FAILED message
  (no attachments), the empty placeholder (id === "") is never replaced. The user is stuck with a phantom empty bubble. Fix: Remove the hasAttachments guard —
  when last.id === "", always replace the placeholder:
  if (last.id === "") {
    return [...prev.slice(0, -1), item];
  }

  2. No abort signal propagation in streamGetMessage polling loop
  client.ts:389-447 — The while(true) polling loop doesn't accept or check an AbortSignal. When the SSE client disconnects, the server keeps polling the
  Databricks API for up to 120s (~40 API calls). The executeStream framework passes a signal via handler(combinedSignal), but the genie.ts handler doesn't
  forward it to streamGetMessage. Fix: Accept signal?: AbortSignal in options, check signal?.aborted before each poll, and use signal-aware sleep.

  3. Double timeout: executeStream interceptor vs. polling loop deadline
  genie.ts:213-214 + client.ts:396-398 — Both the interceptor and the generator have independent 120s timeouts racing each other. If the interceptor fires first,
   the generator gets an unclean termination. Fix: Either remove the internal deadline from streamGetMessage (relying on the signal from the interceptor), or set
   the interceptor timeout slightly longer.

  4. pollPendingMessage Promise has no .catch()
  use-genie-chat.ts:402-425 — The connectSSE call is fire-and-forget with only .then(). If connectSSE rejects for an uncaught reason, the status stays stuck at
  "streaming" forever with an unhandled rejection. Fix: Add .catch() to set error state.

  5. useCallback dependency chain is fragile
  use-genie-chat.ts — The chain processStreamEvent → pollPendingMessage → loadHistory → useEffect is stable today only because processStreamEvent closes over
  stable props. Adding any state dependency (like conversationId) would cause the entire chain to collapse, triggering effect re-fires and history reloads. Fix:
  Store processStreamEvent in a ref to break the identity cascade, making pollPendingMessage and loadHistory stable.

pls double check if that makes sense and create a plan to fix it , if so 👍