Repository navigation
perf(webapp): a teammate's write should not cost everyone the project - #239
Merged
Merged
Conversation
A one-path change invalidated the whole tree, the whole heat map, and every
cached file body in every project open in the tab — the last one twice per
frame, because the bare ["text"] prefix was invalidated in two places. On a
real project that is ~1.8 MB of refetching to say that one file moved, and a
ten-file agent run said it ten times.
The frame names the path. This makes the client act like it.
- Heat is out of the fan-out entirely. It is READ telemetry: it moves when
somebody opens a file, which no write can tell us, so refreshing it on
every write re-sent 133 KB to say exactly what it said before. The
surfaces that show it refresh it when they open, and it carries its own
staleTime.
- ["text"] is scoped to the named path. The live URL is a pure function of
the path (fileURLFor), so the key is knowable at the frame; a ?v= URL is
content-addressed and cannot go stale at all.
- The tree and history coalesce behind a 2s window, so a sync push or a
multi-file agent run costs one refresh instead of N. The tree is the
single biggest response the hub serves.
- Per-path bodies are deliberately NOT delayed. An open file updating is
the thing a reader actually notices, and one body is small.
History needs no "only when mounted" gate: invalidateQueries refetches ACTIVE
queries and only marks inactive ones stale, so a history view nobody has open
already costs nothing.
Not done, and recorded as deferred rather than skipped: patching the tree
cache instead of refetching it. A frame carries paths, not the new
size/time/author, so patching needs the hub to enrich the frame — a server
change with a permissions question attached, since a frame must not name a
path its reader cannot see. The criterion is met without it.
e2e: a second account writes one file and the first client's request count for
that frame is asserted — zero heat, at most one tree, at most two requests
total. Verified failing without the change. Full hub suite: 260 passed, zero
failures, the first entirely green run of the day.
Stage 3 of docs/network-efficiency-prd.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR
What a frame used to cost
~1.8 MB of refetching to say that one file moved.["text"]Heat is the one worth dwelling on: it's read telemetry. It moves when somebody opens a file, which no write can tell us — so refreshing it on every write re-sent the whole map to say exactly what it said before.
What I deliberately did not do
The PRD asks for the tree cache to be patched from the frame rather than refetched. A frame carries paths, not the new size/time/author, so patching needs the hub to enrich the frame — a server change with a permissions question attached, since a frame must not name a path its reader cannot see.
The measurable criterion is met without it, so it's recorded in the PRD as deferred with that reasoning, not quietly dropped.
Also worth noting: history needs no "only when mounted" gate.
invalidateQueriesrefetches active queries and only marks inactive ones stale, so a history view nobody has open already costs nothing.Verification
heat refetched: …/heat?days=30).One honest note: an earlier run showed
home.specfailures and I suspected my own coalescing window. It was the documented admin/hub flake cascade — a clean re-run is fully green. I'd truncated the first run's log totail -12, so I had failure names without reasons and guessed twice before capturing the log properly.🤖 Generated with Claude Code