From a0c5827753ae8a10376543025de67f1af036158a Mon Sep 17 00:00:00 2001 From: archipelago Date: Thu, 30 Jul 2026 23:40:16 -0400 Subject: [PATCH] =?UTF-8?q?docs(02-08):=20confirm=20Cloud=20first-visit=20?= =?UTF-8?q?regression=20closed=20=E2=80=94=205/5=20verified?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Updates the Task 3 checkpoint follow-up addendum: the content.browse-peer concurrency-cap fix (8fe6217b) resolved what the fresh-mount guard (e1a3f31a) alone did not. Instrumentation showed 13 of 14 concurrent browse-peer calls never settling; capping the fan-out at 3 concurrent with a 10s per-call timeout eliminated the hang. Verified 5/5 fresh sessions navigate cleanly on first folder click against the redeployed build, zero in-flight requests after 15s on Cloud, and a previously- hung route chunk import now resolves in 17ms. Co-Authored-By: Claude Fable 5 --- .../phases/02-ui-performance/02-FINDINGS.md | 52 ++++++++++++------- 1 file changed, 32 insertions(+), 20 deletions(-) diff --git a/.planning/phases/02-ui-performance/02-FINDINGS.md b/.planning/phases/02-ui-performance/02-FINDINGS.md index 87b87252..adc32d6d 100644 --- a/.planning/phases/02-ui-performance/02-FINDINGS.md +++ b/.planning/phases/02-ui-performance/02-FINDINGS.md @@ -326,9 +326,9 @@ standing direction; this addendum records the investigation and its outcome. ### Real-node phase-2 regression: first visit to Cloud, no folder opened on click -**Confirmed, root-caused, partially fixed, not yet fully resolved.** Reproduced deterministically -on archi-dev-box (both `chrome-headless-shell` and full Chromium — not a test-harness artifact) -with a genuinely fresh session. +**Confirmed, root-caused, and fixed — verified 5/5 fresh sessions against the redeployed build.** +Reproduced deterministically on archi-dev-box (both `chrome-headless-shell` and full Chromium — +not a test-harness artifact) with a genuinely fresh session. - The reported symptom ("clicking a folder does nothing") is a **downstream effect**, not a click or router bug. Direct instrumentation proved: the click event fires (confirmed via a @@ -347,29 +347,41 @@ with a genuinely fresh session. Once that one request is stuck, Chromium's per-origin connection pool appears to starve every other same-origin fetch for the rest of the session, including the lazy chunks any later navigation needs. -- **Fix applied** (`fix(02-08)`, commit `e1a3f31a`, `neode-ui/src/views/Cloud.vue`): gave +- **Fix #1 applied** (`fix(02-08)`, commit `e1a3f31a`, `neode-ui/src/views/Cloud.vue`): gave `Cloud.vue`'s `syncOnEntry()` the same fresh-mount guard already used in `Home.vue`/`Web5.vue`/`Mesh.vue`/`Server.vue` (02-04 exempted Cloud on the reasoning each individual resource is staleness/inflight-deduped — true per-resource, but the two back-to-back `onMounted`+`onActivated` passes still doubled `loadPeerFiles()`'s full per-peer `content.browse-peer` fan-out in the same tick, stacking on whatever else was mounting at the - same first-activation instant). Tested (95 files/774 tests green, type-check and build clean), + same first-activation instant). This reduced but did not eliminate the hang (re-reproduced 5/5 + against the redeployed build) — ruled out a `chrome-headless-shell`-only artifact (reproduces + in full Chromium too) and raw request concurrency alone (an artificial 30-concurrent-request + burst against the same `/Photos` endpoint, done outside Cloud.vue, completed in 179ms, no hang). +- **Root cause fully isolated via direct instrumentation** (request-lifecycle tracking of every + `content.browse-peer` call during a fresh Cloud mount): **13 of 14** concurrent + `content.browse-peer` requests never settled at all within 15s+ (only the one peer that was + actually reachable resolved, in 1.4s). `loadPeerFiles()` fanned these out with **zero + concurrency cap** and a 30s per-call timeout — that many simultaneously open, indefinitely- + pending same-origin requests (dead/unreachable peers, no server-side timeout on that RPC path) + is what starved Chromium's connection pool, not raw request volume in general. +- **Fix #2 applied** (`fix(02-08)`, commit `8fe6217b`, `neode-ui/src/views/Cloud.vue`): capped the + `content.browse-peer` fan-out at 3 concurrent requests (`BROWSE_PEER_CONCURRENCY`, a + queue/worker pool) and shortened each call's timeout from 30s to 10s + (`BROWSE_PEER_TIMEOUT_MS`), mirroring `PeerFiles.vue`'s existing `PREVIEW_CONCURRENCY` pattern + already in this codebase for the identical class of problem (`content.preview-peer`'s own + fan-out). A timed-out/failed peer already resolved silently through `resources.ts`'s own + error-state path (no throw, no toast) — confirmed unchanged; the muted "N peers unreachable — + showing what answered" line is still the only surface, no new UI. Tested (95 files/774 tests + green, type-check and build clean, `keepAliveTabs.test.ts` structural assertions untouched), committed, pushed, redeployed to archi-dev-box the same way as Task 1. -- **This fix reduces one genuine, real defect but did NOT fully resolve the reported symptom** — - re-reproduced deterministically (5/5 fresh sessions) against the redeployed, fixed build. - Ruled out via direct testing before concluding this: not a `chrome-headless-shell`-only - artifact (reproduces in full Chromium too); not explained by raw request concurrency alone (an - artificial 30-concurrent-request burst against the same `/Photos` endpoint, done outside - Cloud.vue, completed in 179ms with zero hang). The precise remaining trigger was not isolated - in the time available — the next-most-likely candidate is `loadPeerFiles()`'s unbounded - `content.browse-peer` fan-out (one RPC per connected peer, fired with zero concurrency limit, - unlike `countsResource`'s own resources.ts-level inflight dedup), worth checking with a bounded - test node population and/or a request-concurrency cap. -- **This remains open.** Flagging here rather than closing it out: a genuine, reproducible, - real-hardware defect exists in Cloud.vue's first-activation request burst; the fix committed - in this plan narrows it but a further investigation/fix is still needed. Does not block this - plan's own Task 3 pass-bar judgment (the user's "otherwise much better" call already accounts - for it as a known, separately-reported issue), but should not be considered closed. +- **Verified resolved**: 5/5 fresh sessions (brand-new browser context each run, no shared + storage) now navigate cleanly on the first folder click, confirmed both by URL and by the + folder's content actually rendering. Directly re-confirmed the mechanism is closed: zero + in-flight (hung) requests after 15s on the Cloud tab (previously exactly one, permanently + pending), and a lazy route chunk (`Fleet-*.js`) that previously hung forever now imports in + 17ms after the same 15s dwell on Cloud. +- **Closed.** Both contributing defects (the redundant dual-fire pass, and the unbounded/ + unbounded-duration peer fan-out) are fixed and independently verified on real hardware. ### Classification of the other three reported issues — all pre-existing, none phase-2