## Code Analysis ### The status hook preserves delivered state without requiring a support code `frontend/src/hooks/useSupportTicketStatus.ts:6-9,34-40` ```ts export interface SupportTicketDelivery { status: 'pending' | 'sending' | 'delivered' | 'failed' | null; supportCode: string | null; } const poll = async () => { try { const { data } = await api.get(`${statusBasePath}/${clientTicketId}/status`); if (cancelled) return; setState({ status: data.status ?? null, supportCode: data.support_code ?? null }); if (data.status === 'delivered') return; } catch { // Transient — keep polling until MAX_POLLS is exhausted. } ``` The hook stores `data.status` and `data.support_code` independently. A delivered response with a null support code therefore produces `{ status: 'delivered', supportCode: null }`, and polling stops on the delivered status. ### The form requires both delivery and an optional code `frontend/src/components/support/SupportTicketForm.tsx:119-135` ```tsx {submittedId && (

{t('requestQueued')}

{delivery.status === 'delivered' && delivery.supportCode ? ( <>

{t('supportCode')}: {delivery.supportCode}

{t('supportCodeHint')}

) : ( <>

{t('requestId')}: {submittedId}

{delivery.status === 'failed' ? t('stillQueuedLocally') : t('confirmingDelivery')}

)}
)} ``` When `delivery.status` is `delivered` but `delivery.supportCode` is null, the condition is false. Rendering falls through to `confirmingDelivery`, so the UI does not acknowledge the definitive delivered state. ### The status API makes support code nullable `main/routes/support-ticket.ts:108-115` ```ts function statusHandler(req: Request, res: Response) { const clientTicketId = String(req.params.clientTicketId || ''); if (!CLIENT_TICKET_ID_RE.test(clientTicketId)) return res.status(400).json({ error: 'invalid client_ticket_id' }); const row = getDatabase().prepare( 'SELECT status, support_code, last_error FROM support_ticket_outbox WHERE client_ticket_id = ?' ).get(clientTicketId) as { status: string; support_code: string | null; last_error: string | null } | undefined; if (!row) return res.status(404).json({ error: 'not found' }); res.json({ status: row.status, support_code: row.support_code, last_error: row.last_error }); } ``` The server response explicitly exposes `status` separately from nullable `support_code`, so a null code does not negate a delivered status. ### Observed execution ### status requests and responses ```text POST http://localhost:3001/api/support-ticket/pre-login => 202 Accepted GET http://localhost:3001/api/support-ticket/pre-login/a163f934-b7ab-4a89-8404-184bda366557/status => 200 OK GET http://localhost:3001/api/support-ticket/pre-login/a163f934-b7ab-4a89-8404-184bda366557/status => 200 OK ``` ```json {"status":"pending","support_code":null,"last_error":null} {"status":"delivered","support_code":null,"last_error":null} ``` ### UI readback ```text Request ID: a163f934-b7ab-4a89-8404-184bda366557 Confirming with the support server… No visible "delivered" text was present in the page snapshot. ``` # final result: The second status response was delivered, but the submitted-ticket dialog remained on “Confirming with the support server…” because the delivered rendering branch also requires a non-null support code. ### Test context The local test used a test-only delivery transition from pending to delivered and disabled cloud sync so the anonymous flow could run locally. The captured HTTP response and UI readback are runtime evidence; the source excerpts explain the rendering path.