Skip to content

[Bug]: React #185 crash after sending a message when client clock lags server #2087

Description

@ktritz

Before submitting

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

Area

apps/desktop

Steps to reproduce

  1. Use a client machine whose clock is slightly behind the backend/server clock.
  2. Open an existing thread.
  3. Send a message such as ping.
  4. Let the turn complete/settle.
  5. The app can crash with the generic error screen showing Minified React error #185.

Expected behavior

The thread should settle normally, remain open, and mark itself visited without crashing, regardless of small client/server clock skew.

Actual behavior

Actual behavior

After sending a message and the turn completes, the app can enter an infinite update loop and crash with:

Minified React error #185

This corresponds to React's Maximum update depth exceeded.

Impact

Major degradation or frequent failure

Version or commit

Observed in stable and in nightly desktop client 0.0.18-nightly.20260416.46

Environment

Windows desktop app talking to a Linux backend over the network. Observed on: - Windows 11 desktop client - Linux backend - Backend/client clocks differed by roughly 0.6-0.7s, with the client behind

Logs or stack traces

Crash dialog:

`Minified React error #185; visit https://react.dev/errors/185 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.`

Observed stack excerpt:

  
  Error: Minified React error #185
      at Bo (http://127.0.0.1:3773/assets/index-....js:9:52284)
      at markThreadVisited (http://127.0.0.1:3773/assets/index-....js:45:85080)

Root cause is the ChatView settled-turn effect calling markThreadVisited(...) without passing the server completion timestamp, so the client uses local wall-clock time and can loop forever when client_time < server_completedAt.

Screenshots, recordings, or supporting files

No response

Workaround

Temporary operational workaround: keep the client clock closely synchronized with the server clock.

Actual code workaround / fix:

In apps/web/src/components/ChatView.tsx, change:

markThreadVisited(scopedThreadKey(scopeThreadRef(serverThread.environmentId, serverThread.id)));

to:

markThreadVisited(
  scopedThreadKey(scopeThreadRef(serverThread.environmentId, serverThread.id)),
  activeLatestTurn.completedAt,
);

This avoids using client wall-clock time when marking a settled thread as visited and prevents the render loop when the client clock lags the server clock.

Activity

  1. added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Apr 16, 2026
  2. matty commented on Apr 29, 2026

    @matty

    I use remote feature heavily and this one comes up a lot and disrupts workflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions