kayg/calternal

Watch

Fork 0

REGRESSION: Files opens slowly ('Opening Files…' for long) on calternal.cloud today — bisect, fix, add route-timing budget #522

New issue

Closed

opened 2026-09-30 14:13:03 +00:00 by kayg · 5 comments

kayg commented

2026-09-30 14:13:03 +00:00

Owner

REGRESSION (owner, 2026-09-30 ~16:10 CEST, calternal.cloud at `5d6d22e60`): "why does it take so long to open files now?"

Opening Files shows "Opening Files…" for a long time. The production server is idle (load 0.05, 4% CPU), so the delay is probably on the client (a request chain, a waiting promise, a lazy import, a store waiting on SSE, or a new preference/visibility fetch) or on one slow endpoint.
Find it with data, then fix it:

Bisect by deploy: today's deployed commits were 99288dcfe (fast, 04:43) → 6c87f5ff9 → f709fe0fe → 5896bf2bc → 8ac92b400 → 1aaefe288 → 5d6d22e60. Build the web app at each suspicious commit (or git bisect with a scripted timing check) and measure the time from navigation to the first file row on a real local server with a realistic Home (a few thousand files; reuse the bench large-Home fixture at a smaller scale).
Record the network waterfall and main-thread long tasks (Playwright tracing plus a performance profile) for /files at the good and bad commits. Name the exact request or code path that waits.
Fix the root cause, then add a route-timing budget to the e2e (route-perf.mjs) so /files first rows must paint within the budget (measure the baseline; pick a budget like p95 ≤ 500 ms locally).
Check the other tabs for the same regression (Calendar, Photos, Mail, Money, Analytics) with the same timing.
Report the culprit commit, the numbers before and after, and the head SHA on the issue. Web gates, plus Rust per crate if a server endpoint is at fault.

## REGRESSION (owner, 2026-09-30 ~16:10 CEST, calternal.cloud at 5d6d22e60): "why does it take so long to open files now?" Opening Files shows "Opening Files…" for a long time. The production server is idle (load 0.05, 4% CPU), so the delay is probably on the client (a request chain, a waiting promise, a lazy import, a store waiting on SSE, or a new preference/visibility fetch) or on one slow endpoint. **Find it with data, then fix it:** 1. Bisect by deploy: today's deployed commits were 99288dcfe (fast, 04:43) → 6c87f5ff9 → f709fe0fe → 5896bf2bc → 8ac92b400 → 1aaefe288 → 5d6d22e60. Build the web app at each suspicious commit (or `git bisect` with a scripted timing check) and measure the time from navigation to the first file row on a real local server with a realistic Home (a few thousand files; reuse the bench large-Home fixture at a smaller scale). 2. Record the network waterfall and main-thread long tasks (Playwright tracing plus a performance profile) for /files at the good and bad commits. Name the exact request or code path that waits. 3. Fix the root cause, then add a route-timing budget to the e2e (`route-perf.mjs`) so /files first rows must paint within the budget (measure the baseline; pick a budget like p95 ≤ 500 ms locally). 4. Check the other tabs for the same regression (Calendar, Photos, Mail, Money, Analytics) with the same timing. Report the culprit commit, the numbers before and after, and the head SHA on the issue. Web gates, plus Rust per crate if a server endpoint is at fault.

kayg commented

2026-09-30 14:25:08 +00:00

Author

Owner

Related: #521 (cold Photos Tab switch stays on 'Opening Photos'). Same 'Opening …' symptom; check the same code path and fix both.

Related: #521 (cold Photos Tab switch stays on 'Opening Photos'). Same 'Opening <Tab>…' symptom; check the same code path and fix both.

kayg commented

2026-09-30 15:07:54 +00:00

Author

Owner

Owner (2026-09-30, second screenshot during Files load): "for a brief moment during load, i can see the old background?" and "i would definitely like loading to be faster. loading should be instantaneous. animations are what should take time."
Add to this fix (same code path):

Background flash: on load, the previous (default/theme) background paints before the User's chosen background. The User's appearance (scheme, theme, background kind, picture thumbnail) must apply before first paint: persist the last applied appearance locally and apply it in an inline boot script, and render the picture's cached low-res thumbnail immediately, swapping in full resolution without a flash. No visible change when the server copy arrives unless it differs.
"Loading 0 items… / 0 items" text must never show. Tabs render instantly from the last known data (a per-User cached listing in IndexedDB or the SvelteKit cache), then revalidate in the background and update in place (stale-while-revalidate). A first-ever visit shows the real layout immediately (header, column header, rows as they stream), never a text placeholder.
Budget: from navigation to content visible within one frame of the route change when cached, and to fresh content within the API p50. Add these to route-perf.mjs for Files, Photos, Calendar, Mail, Money and Analytics.

**Owner (2026-09-30, second screenshot during Files load):** "for a brief moment during load, i can see the old background?" and "i would definitely like loading to be faster. loading should be instantaneous. animations are what should take time." Add to this fix (same code path): 1. **Background flash:** on load, the previous (default/theme) background paints before the User's chosen background. The User's appearance (scheme, theme, background kind, picture thumbnail) must apply before first paint: persist the last applied appearance locally and apply it in an inline boot script, and render the picture's cached low-res thumbnail immediately, swapping in full resolution without a flash. No visible change when the server copy arrives unless it differs. 2. **"Loading 0 items… / 0 items" text** must never show. Tabs render instantly from the last known data (a per-User cached listing in IndexedDB or the SvelteKit cache), then revalidate in the background and update in place (stale-while-revalidate). A first-ever visit shows the real layout immediately (header, column header, rows as they stream), never a text placeholder. 3. **Budget:** from navigation to content visible within one frame of the route change when cached, and to fresh content within the API p50. Add these to `route-perf.mjs` for Files, Photos, Calendar, Mail, Money and Analytics.

kayg commented

2026-09-30 16:26:04 +00:00

Author

Owner

Related: #528 (Photos navigation can remain on the loading route). Same 'Opening/loading' family as #521; fix together.

kayg referenced this issue

2026-09-30 17:22:40 +00:00

Background picture intermittently replaced by the theme gradient (boot and in-app navigation) #535

kayg referenced this issue

2026-09-30 17:24:17 +00:00

Background picture intermittently replaced by the theme gradient (boot and in-app navigation) #535

kayg commented

2026-09-30 17:38:00 +00:00

Author

Owner

#535 traced the shared boot bug: the shell's inline script restores scheme/theme but not the background, and the root #app-background itself is already outside route content. I am implementing one calternal.appearance-boot snapshot in the existing inline boot script, with backgroundStore as its writer. It will apply the last decoded low-res picture before paint, keep the picture layer while a replacement decodes, and suppress the theme mesh while an image is selected. #522 can reuse this same implementation rather than adding a second boot path.

#535 traced the shared boot bug: the shell's inline script restores scheme/theme but not the background, and the root `#app-background` itself is already outside route content. I am implementing one `calternal.appearance-boot` snapshot in the existing inline boot script, with `backgroundStore` as its writer. It will apply the last decoded low-res picture before paint, keep the picture layer while a replacement decodes, and suppress the theme mesh while an image is selected. #522 can reuse this same implementation rather than adding a second boot path.

kayg commented

2026-09-30 18:22:21 +00:00

Author

Owner

Fixed and deployed in 15e17aeaf (calternal.cloud healthy): pressing a tab no longer changes its width before the click, so Files opens. Remaining first-row time (0.8–1.1 s under build-host load) is tracked by #549 (tab switch on HDD).

Fixed and deployed in 15e17aeaf (calternal.cloud healthy): pressing a tab no longer changes its width before the click, so Files opens. Remaining first-row time (0.8–1.1 s under build-host load) is tracked by #549 (tab switch on HDD).

kayg closed this issue

2026-09-30 18:22:22 +00:00

kayg referenced this issue

2026-09-30 18:22:30 +00:00

Prevent Tokio worker stack overflow during adversarial API load #519

kayg referenced this issue

2026-09-30 20:17:42 +00:00

Web: full page reloads on in-app navigation after deploys (old build chunks gone); keep previous immutable assets, graceful update #423