[Bug] Controls become unresponsive in long-running threads

[Runiir]

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. Open the T3 Code iOS app.
2. Open a thread and start a task that runs for a relatively long time.
3. While the thread is still actively running, try to send another message from the iPhone.
4. After the thread has been running for some time, the message may no longer be sent when pressing Send.
5. Try pressing the Stop button for the currently running task.
6. The Stop button may also stop responding.
7. Open an image attachment from the thread.
8. Try pressing the Close or Open buttons in the image viewer.
9. These buttons can also become unresponsive.

The issue seems to happen primarily with long-running / actively streaming threads. It is not always immediate, so I do not yet have a precise runtime after which it starts happening.

Expected behavior

The iOS UI should remain interactive regardless of how long a thread has been running.

In particular:

• Sending another message should work while a thread is running, if supported.
• The Stop button should reliably stop/cancel the current run.
• The Close and Open buttons in the attachment/image viewer should remain tappable.
• A long-running thread should not cause unrelated UI controls to stop registering taps.

Actual behavior

After a thread has been running for a while, multiple controls can stop responding to taps.

I have observed all of the following:

• Messages are not sent to the running thread when pressing Send.
• Pressing Stop does nothing.
• When opening an attached image, the Close and Open buttons also do nothing.

The app does not appear completely frozen. The UI is still visible and navigable in some places, but these interactive controls no longer register taps.

Because controls in different parts of the UI are affected at the same time, this may be a broader iOS touch/input issue rather than an isolated problem with the Send or Stop button.

Related issues

This may overlap with two existing issues, although the native iOS behavior here appears broader:

• [Bug]: Thread cannot be stopped #2234 — Thread cannot be stopped. This looks particularly relevant because it has been reported after extended/large-thread usage, and discussion there suggests that in some cases the underlying process had already stopped while T3's persisted session state remained stuck as running.
• [Bug]: No way to send a follow-up mid-turn on mobile viewports — send button is replaced by stop and Enter-to-send is disabled below sm #4775 — No way to send a follow-up mid-turn on mobile viewports. This may overlap with the inability to send messages during an active turn, although [Bug]: No way to send a follow-up mid-turn on mobile viewports — send button is replaced by stop and Enter-to-send is disabled below sm #4775 describes a mobile-web responsive UI limitation rather than native iOS controls becoming unresponsive. The native T3 iOS app also cannot be rotated to landscape, so the landscape workaround described there does not apply.

The additional symptom that seems distinct in this issue is that, when it occurs, controls unrelated to the running thread also stop accepting taps — for example Close/Open in the image attachment viewer.

That makes me unsure whether this is entirely explained by the existing thread/session-state issues, or whether the native iOS client also develops an interaction/touch-layer problem after a long-running thread.

Impact

Blocks work completely

Version or commit

1.0.3 for ios app

Environment

Ios 18.7.8

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[lnieuwenhuis]

Could you maybe add a screen recording of this issue? One for the normal, expected behaviour, and one for the laggy, unresponsive one, with the difference between the threads explained exactly. It may just be the amount of data that's rendered at once (or in the background) because of a long-running task.

[Runiir]

The thread crashed yesterday and now starting it again seems to be working relatively fine. I will keep an eye out and post evidence as I get them

[Runiir]

trim.93E42FC2-AE20-47AA-B273-E4470A30C324.MOV

I managed to replicate. Now not even the thread item opens. I pressed it multiple times and also tried o long press.

[Runiir]

Update. The job stopped but it took like 20-30 min

[Runiir]

Here the stop button doesnt do anything. https://github.com/user-attachments/assets/1bc88892-32c3-47c5-8f36-503a37264848

[lnieuwenhuis]

Here the stop button doesnt do anything. https://github.com/user-attachments/assets/1bc88892-32c3-47c5-8f36-503a37264848

@Runiir , I'm currently working on a pretty broad fix in the PR now attached to your issue, I think I have most of the client side issues covered, but it turned out into a pretty big PR, so unless one of the maintainers looks for fixes specifically for your issue, there's a pretty small chance it gets merged. For now, I think I have enough

[neocody]

Independent iOS corroboration: this is happening frequently in normal use, even when simply switching among existing sessions.

Observed behavior:

• After the app has been left open, tapping a session often does nothing.
• When a tap does register, the page can take several seconds to begin loading and roughly 10–20 seconds to show the conversation.
• Sometimes the conversation never opens at all.
• Switching to other sessions becomes increasingly laggy or unresponsive until the app is force-quit and relaunched.
• Relaunching temporarily restores responsiveness, but the problem returns.

Impact: this makes the iOS app unreliable for routine session switching and repeatedly interrupts work. I believe this should be treated as a high-priority mobile reliability/performance issue.

This also appears adjacent to #7390, which identifies repeated full-feed rebuilding during large or active threads, and #5477, which tracked slow repeat opens of long-lived sessions. I cannot confirm the same root cause, but this report matches this issue's observed symptom that thread items stop opening.

[neocody]

Here is a screen recording showing the issue and then some. Often when I'm typing out a response the message box just completely disappears, and I am randomly reposition to a different part of the conversation. Then I have to scroll all the way back down, but no matter how far down I scroll the message box never appears I have to tap the conversation and then the message box will appear again

https://share.icloud.com/photos/0e1TfMiDIvjdi2fb8KoNM87ZA

[juliusmarminge]

Closing as fixed by #8309 (and the batch apply already on main from #11302).

This PR’s original commits called out #8118 / #4596 as the mobile + backlog-replay freezes; GitHub didn’t auto-close because the final PR body dropped the Closes keywords. The client-runtime now batches received updates and keeps settled turns / older-page loading correct under that path.