[ragnorc]

Problem

Reviews on the hosted personal graph often failed with "Could not reach the server: the request timed out". Studio gave every read 60 s. The server works out a whole page of changes before it answers, and it sets no deadline of its own. On the personal graph (server 0.14.1-edge+7711e4a, measured 2026-10-25), one review page took 37–62 s. So a review landed on either side of the limit, and went over it when the server's caches were cold.

The slowness is in the engine:

• performance: graph diff and branch review read both full tables unless the endpoints are one transaction apart omnigraph#969: a diff reads whole tables unless its two ends are one transaction apart. A 350-change diff from a branch's merge base took 60.3 s cold and 37–43 s warm. Of that, 47.6 s was spent on Artifact, a type of about 100,000 rows that the branch changed 3 times.
• performance: a commit lookup that misses the current branch checks out every live branch's __manifest omnigraph#972: a commit that only a branch holds is looked up in every live branch, which adds 6–9 s to each read that names one.
• performance: a client cannot bound how long one change-feed page takes omnigraph#1157: a client cannot bound how long one change-feed page takes. A page covering 9 commits took 54.4 s.
• rfc: discover changes by fragment identity omnigraph#1171: a draft RFC to find changes by fragment identity, with a commit ceiling for the feed.

What changes

• graph_client: reads of changes now wait up to 300 s, as a write does (CHANGE_READ_TIMEOUT). These are the change feed, GET /diff, one commit's changes, and the merge dry run. Every other read stays at 60 s. Reads are still never sent twice, except on the existing 429 path. History's commit view and row counts and Undo read a commit's changes through the same route, so they wait as long too.
• Timeouts: a request the server took and did not answer is now told apart from a connection that never opened (ReadError::timed_out). The second now reads "the connection timed out".
• Review, while slow: after 10 s the review reads "The server is still working out the changes…", with "On a large graph this can take a few minutes." under the header.
• Review, after a timeout: a page the server did not answer in 5 minutes reads "The server was still working out the changes after 5 minutes, and Studio stopped waiting." The failed review now offers Refresh.
• Spec 008: the measurements, the design note, and why a review of a branch its target was merged into still names its head by commit id. Naming the branch would save the performance: a commit lookup that misses the current branch checks out every live branch's __manifest omnigraph#972 lookup, but a diff's page token binds every later page to the first page's spelling. A moved branch could then only be caught by reading that page again by commit id.
• Spec 012 and docs/deferred-engine-changes.md: new entries E35–E38, for performance: graph diff and branch review read both full tables unless the endpoints are one transaction apart omnigraph#969, performance: every change page restarts its comparison (re-plan, re-resolve endpoints, re-sort keys) omnigraph#970, performance: a commit lookup that misses the current branch checks out every live branch's __manifest omnigraph#972 and performance: a client cannot bound how long one change-feed page takes omnigraph#1157.

Testing

• New tests: graph_client a_read_of_changes_waits_longer_than_other_reads and a_timeout_says_whether_the_server_was_reached; review a_slow_review_says_the_server_is_still_working and a_review_that_timed_out_says_the_server_was_still_working.
• On this branch, rebased onto main at 9ec4e68: cargo test --workspace --no-fail-fast (1,043 passed, 0 failed), cargo clippy --workspace --all-targets -- -D warnings, cargo fmt --all --check, python3 script/check-layers.py, script/check-brand.py and script/check-design-tokens.py all pass.
• Not tried in the running app against the personal graph.

---

Note

Medium Risk
Touches HTTP timeout plumbing and review loading/error paths used on every branch review; behavior change is intentional but affects reliability UX on slow graphs rather than security or writes.

Overview
Reviews on large graphs were failing at the old 60 s read limit because the server finishes an entire change page before responding, which often takes close to or over a minute.

graph_client now uses a public CHANGE_READ_TIMEOUT (300 s)—matching write timeout—for the change feed, GET /diff, per-commit changes, and merge dry run; other reads stay at 60 s. fetch / read_within take an explicit timeout, and ReadError::timed_out() distinguishes a slow server response from a connection that never opened (clearer “request timed out” vs “connection timed out” messaging).

Review UI after 10 s shows that the server may still be computing changes; on failure after 5 minutes it explains Studio stopped waiting (not “could not reach the server”) and adds Refresh. Spec/docs record engine deferrals E35–E38 and validation for the new behavior.

^{Reviewed by Cursor Bugbot for commit b90ca37. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: df6fb8ed-25e2-49fa-a916-ee1394ca4f8a)