fix(mothership): keep a failed direct send ahead of follow-ups queued during its POST

[waleedlatif1]

Summary

• A failed direct send goes back to the head of the queue. When a direct send's POST failed (offline, a network blip, or a busy refusal), the message was re-queued at the tail, behind any follow-up typed while that POST was out. The queue became [B, A], and the drain could send the follow-up before the message written first.
• Why the head is right: a direct send only goes out when nothing is queued ahead of it (shouldQueueOutgoingMessage), so anything queued while its POST was out was written after it. It now goes back with insertAt(…, 0).
• Why tests missed it: every existing direct-send test sent its follow-up only after the first send had resolved, so a follow-up never queued during the POST.

Type of Change

• Bug fix

Testing

• keeps a failed direct send ahead of a follow-up queued during its POST, for offline, an online network blip, and a busy 409. Each fails on staging: the follow-up is sent ahead of the first message.
• The full gate and integration tests ran on the CI runner.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Oct 7, 2026 9:04am UTC

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Fixes message queue ordering when a direct send fails.

The PR appears safe to merge.

What we checked:

• Older messages keep their place: A direct send starts only with an empty queue. It marks the chat as sending before waiting, so follow-ups join the queue behind it.
• Browser mocks reset between tests: The app uses the shared Vitest configuration, which restores spies and globals before each test.

Summary

Failed direct sends now return to the front of the chat queue, ahead of follow-ups written while their POST was pending.

• Adds regression coverage for offline failures, online network failures, and busy refusals.
• Keeps the existing request identity, retry flags, and retry timing.
• No actionable issues found.

Diagram

sequenceDiagram
    participant User
    participant Chat
    participant Server
    participant Queue
    User->>Chat: Send A with an empty queue
    Chat->>Server: POST A
    User->>Chat: Send B while POST A is pending
    Chat->>Queue: Append B
    Server-->>Chat: A fails or is refused
    Chat->>Queue: Insert A at the front
    Note over Queue: Queue order is A, then B

Loading

_{Reviews (1) · Last reviewed commit: "fix(mothership): keep a failed direct se..." · Reviewed by Greptile}