Repository navigation
[Bug]: Mobile: a follow-up the server queues disappears from the thread until its run starts #25282
Description
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
- On mobile, open a thread with an active turn.
- Send a follow-up that the server queues instead of steering. Two ways to get there:
- Settings → Follow-ups set to Queue, then send while the turn runs.
- With the default (Steer), send while the active run is still starting, between provider turns, or running
/compact.resolveDeliveryIntentinapps/server/src/orchestration-v2/CommandPolicy.tsqueuesautofollow-ups in those cases (queue_after_active).
- Watch the feed after the send is accepted.
Expected behavior
The follow-up stays in the feed, marked as queued, until its run starts. Web keeps the queued text visible in QueuedRunsControl above the composer.
Actual behavior
The message shows as Pending, then disappears from the feed once the server accepts it. The only trace is the count on the floating working control; the text is visible only after opening the queue sheet. It reappears when its run starts. During a long turn it looks like the message was swallowed.
As far as I can trace it on main @ f88b33a:
- A queued run's user message has no turn item until the run starts, so the feed built by
deriveThreadFeedPresentationdoes not include it. appendPendingThreadMessages(apps/mobile/src/features/threads/pending-thread-feed.ts) shows the outbox copy only while the outbox holds it, and the outbox drops it once the send succeeds.- Mobile reads the server queue only for the count and the sheet (
ThreadQueueControl.tsx,floating-working-control.tsx).
Impact
Minor bug or occasional failure
Version or commit
main @ f88b33a (code trace). Seen on a fork build based on 0b42aa9.
Environment
Android app built from source, connected over Tailscale to a Linux x64 server.
Workaround
Open the queue sheet from the floating control to see the message.
For reference, our fork appends each queued run's message after the presented feed, labelled Queued in place of its time, unless the feed already shows it: jason5545@8722a86cb1 (with a test).
Activity
docs: link the upstream reports filed for fork patches
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
On origin/main 2ed6f10: started an isolated dev server (T3CODE_DEV_SEED=0 vp run dev --host 0.0.0.0, fresh database) and Metro (apps/mobile vp run dev:client). Added a demo git project and started a Replay (dev) thread with the 'question' scenario via
node apps/server/src/bin.ts thread start --provider devReplay --model question;thread showconfirmed it staysrunning, waiting for an answer, so it is an active turn to send a follow-up into. (The 'approval' scenario auto-completes in full-access mode.)vp run mobile:install android --prepareandios --prepareboth found cached clients. Leased a Pixel 9 twice and an iPhone 18 Pro once from the device pool. Each time simlock ended the lease ('UNAUTHORIZED: lease ended by simlock') or the daemon reported 'Remote daemon is unavailable' whilevp run mobile:install --sessionwas installing the dev client, so the app never ran on a device. Planned next steps were: pair, set Settings → Follow-ups to Queue, open the running thread, send a follow-up, and watch the feed. Code on main matches the report: ThreadFeed.tsx passes only outbox messages to appendPendingThreadMessages; selectPendingAcknowledgedMessages (use-thread-composer-state.ts) drops an acknowledged message once the server queue holds it; nothing adds server-queued runs to the feed.Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.