TESTNG: Track remote mobile hydration latency on unstable networks

[Yo-DDV]

Hi,

I'm opening this to collect feedback around the remote mobile path on Linux.

I often leave the Linux desktop app running on my computer and connect back to an existing conversation from the mobile app. On long sessions, opening the thread could take a long time before the conversation and active tool updates became usable.

I tested a local build that deduplicates in-flight conversation hydration reads in the Linux remote mobile patch. In my case it is a clear improvement: opening an existing conversation from mobile is noticeably faster, and tool-call updates appear much more quickly.

Network context for this test:

• I tested from France over a French 4G/5G mobile network, not from a stable wired LAN.
• The desktop-side capture was taken on an interface with MTU 1420 towards the Cloudflare TLS endpoint used during the session.
• The local 60-second capture had 6,805 packets, 0 tcpdump/kernel drops, no TCP RST, no zero-window condition, and 16 duplicate data segments.
• ss -tinp showed retrans counters and a transient send queue/notsent state that later drained.

Local app-side observations after restart:

• remoteControl/status/read: up to 1 ms
• thread/read: up to 40 ms
• thread/list: up to 504 ms
• no new refresh_remote_control_for_local_identity_failed entries after restart

I am not attaching the raw pcap here because it contains local connection metadata, but these are the relevant capture notes.

I plan to send a small PR that keeps the current queueing behaviour but avoids launching several concurrent readThread hydrations for the same missing thread. It would be useful to hear whether other users see the same improvement, especially on long threads or unstable mobile networks.

Useful feedback would be:

• distribution and package format
• whether remote-mobile-control is enabled
• mobile network type, Wi-Fi, or wired baseline
• rough before/after time to open a long thread
• logs around turn/started, thread/read, thread/list, and remote-control status calls

[Yo-DDV]

This issue needs your input to gather feedback from real-world experience. Thanks to everyone who takes part!

[ilysenko]

thanks I merged it. If anything goes wrong, please let me know, and I’ll revert it.

[joshyorko]

Just saw this, will report back with some notes I have some

[Yo-DDV]

Hi, thanks, that would be useful.

One more data point from my side: I am still seeing a very clear improvement on French mobile networks, using 4G/5G rather than fiber. With long-running conversations that have a lot of history, opening the thread from mobile could previously take close to a minute in the worst cases. With the current change, the same kind of thread is usually opening in roughly 4 to 8 seconds for me on a cellular connection.

I will keep testing on unstable mobile links too, but so far the difference is very noticeable on my setup.

[Yo-DDV]

Hi, quick follow-up on this.

I opened #666 for two stale stream-state cases I hit while testing long remote mobile sessions from Android. It does not replace the hydration coalescing change already merged in #663; it adds two recovery guards around completed stream items and the terminal active status.

The PR includes regression coverage plus the same patcher idempotence check against a copied installed bundle. Thanks again for the feedback, and I’ll keep an eye on any other notes from longer mobile sessions.

[Yo-DDV]

Hi, quick follow-up on this.

I opened #677 for another remote mobile state recovery case I ran into while testing long Android sessions.

The reason it looked stuck on my side is pretty specific. The desktop app-server had already handled the turn, but the Android view could still have a stale local conversation entry. When a late turn/completed or item/completed notification arrived in that state, the current Linux bundle logged it as an unknown conversation and dropped it. Leaving the thread and opening it again forced a fresh thread read, which is why the mobile view suddenly caught up.

The PR makes the Linux webview recover that case by hydrating the missing conversation, queueing the late notification, then replaying it once the thread is available. I kept it in the core Linux patch path because my current install only has read-aloud and conversation-mode enabled, so a remote-mobile-control-only fix would not cover the standard path.

I added regression coverage for late completed turn/item events, for queued events while hydration is still in flight, and for the current installed bundle name so the patch actually applies to real builds.

Thanks again for keeping this thread open for remote mobile feedback.

[Yo-DDV]

Quick note to keep this tracking thread connected.

#691 has now been merged. It targets a narrower hydration case: summary-only app-server thread reads could create a ghost New conversation entry when the thread had no local rollout available. It does not replace the latency and stale-state feedback tracked here, but it sits in the same remote-mobile hydration area.

I had left one note there about already-patched installed bundles, because fresh rebuilds and re-patching an existing installed content tree may not behave the same way. Since the PR is merged, this is something I’ll keep an eye on while testing updated builds too.

If anyone is testing or working on remote mobile hydration/state issues, it would be helpful to keep notes linked back here too: package format, enabled Linux features, fresh rebuild vs existing install/update, mobile/Wi-Fi network context, and rough before/after behavior. That should make the feedback easier to compare instead of splitting it across separate PRs.

Thanks again to everyone testing this path.

[joshyorko]

@Yo-DDV im already noticing the difference ty

[Yo-DDV]

Ah nice, thanks Josh, really glad to hear that.

I am seeing the same kind of improvement on my side too. The thread opening / hydration path is much better now, especially with longer Android remote sessions over mobile data.

There are still a couple of rough edges on my side. The main one I still hit on Android is that, after a long turn has actually finished, the mobile UI can keep showing the stop button as if the conversation were still running. Leaving the thread and opening it again refreshes the state and lets me send the next message.

At the moment I do not see a clear Linux-side bottleneck for that remaining case. The hydration path itself looks much healthier now, so I am going to keep watching it for another week or two before guessing too hard. It may end up being an upstream mobile/app state-sync issue, but I do not want to overstate that without more data.

If you notice a pattern on your side, especially long threads, Android vs iOS, mobile data vs Wi-Fi, and whether leaving/reopening the thread fixes it, that would be useful to compare. Let's keep each other posted.