Repository navigation
[Bug] Controls become unresponsive in long-running threads #8118
Description
Activity
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.
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
Reacted by Lars Nieuwenhuistrim.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.
Update. The job stopped but it took like 20-30 min
Here the stop button doesnt do anything. https://github.com/user-attachments/assets/1bc88892-32c3-47c5-8f36-503a37264848
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
Reacted by RuniirIndependent 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.
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
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.
Before submitting
Area
apps/mobile
Steps to reproduce
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:
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:
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:
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 belowsm#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