[Bug]: Mobile hides send failures: the message goes back to the composer with no error

[shivamhwp]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

Steps to reproduce

1. On the iOS app, open a thread whose send will be rejected by the server. The easiest way: a thread whose provider instance doesn't exist on the server, for example a custom instance from another machine's settings.json.
2. Type a message and tap Send.
3. Watch the thread for 30 seconds.
4. Open Settings, then Environments, then +, Add environment.

Expected behavior

The thread tells me the message wasn't sent and why, the same way web shows the error in a banner on the thread.

Actual behavior

The message shows as Pending for about a second, disappears, and the text goes back into the composer. Nothing else happens: no banner, toast or alert. It looks like the tap didn't register. Tapping Send again does the same thing.

The error text isn't lost. It turns up later on the Add Environment screen as if pairing had failed: "No orchestration provider adapter is registered for codex-p."

Impact

Minor bug or occasional failure

Version or commit

main at efecd3cf8b. Fresh iOS dev client built from main.

Environment

iPhone 17 Pro simulator, iOS 26.5. Local server from the same checkout. Provider instance codex-p missing on the server.

Logs or stack traces

Metro shows one warning per tap and nothing on screen:

WARN  [thread-outbox] queued message delivery failed {"action": "restore", "stage": "start-turn", ...}

The server rejects the dispatch with "No orchestration provider adapter is registered for codex-p." and sends that text back to the client.

Screenshots, recordings, or supporting files

Typed, then 0s, 2s and 25s after tapping Send. The message goes back into the composer and no error appears:

The same error later shows up on the Add Environment screen:

Recording (20s, downloads as MP4): https://gist.githubusercontent.com/shivamhwp/4e915e04ae090391e5baedf2801e3d59/raw/9df0003b3a357a756e2d78c75b758ece0410f699/send-failure.mp4

Cause

When the outbox can't deliver a message for a reason other than the network, restoreRejectedQueuedMessage puts the text back in the composer and calls setPendingConnectionError(message) (apps/mobile/src/state/use-thread-outbox-drain.ts). That writes one global value, and the only screen that renders it is Add Environment (ConnectionsNewRouteScreen.tsx). The thread screen only shows the environment's own connection error, and only while it's disconnected.

The thread screen used to show this value. #2978 removed it in June.

The same hidden slot is used by other thread actions too: composer attachment limits, queued-message edit conflicts, git status refresh, and review comment image picks. So those errors are also invisible on mobile.

Any start-turn rejection that isn't a network error takes this path: a deleted or renamed provider instance, a missing permission, a policy rejection, a rejected attachment.

Related

• [Bug]: Mobile messages return from Pending to the composer on desktop-created threads #11907 had the same symptom (back to the composer from Pending, no error). It was closed after its server-side cause was fixed, but the missing feedback stayed.
• fix(mobile): keep pending tasks queued when a send fails in flight #10245 sorted network failures into retry. The restore path was left as it was.

Workaround

None in the app. The reason only shows up later on the Add Environment screen.