Investigate stale Preview state during client-side job switches #116

New Issue

2026-10-16T22:50:14Z

eleith-gitea-agent Bot commented

2026-10-16 22:50:14 +00:00

Problem / evidence

The Preview job layout initializes status, errors, phases/logs, tab URLs and its EventSource once. If SvelteKit reuses that layout during direct client-side navigation from job A to job B, the URL/data can belong to B while job-local state, navigation links or observation still belong to A.

This predates PR #115: the same initialization/lifecycle is present in its base 7fae03e5bbce7d981fbda08af01b1f97dbefd211. This is a source-level finding, not a live browser reproduction or a newly introduced PR regression. Normal Back to editor → Preview navigation is not the suspect path; switching tabs within the same job should preserve state.

Reproduction to verify

Use two retained, existing Preview jobs A and B; no new jobs are required.
Open A, then follow an internal same-origin link directly to B so navigation is client-side. Pasting B into the address bar reloads the app and is not this test. The current UI has no ordinary job-switch control; a temporary developer-inserted anchor is sufficient for investigation.
Check that B is in the address bar, then inspect tab hrefs, status, phases/logs and any open progress stream. Suspected failure: A's links/state/subscription persist.
Reload B and compare; fresh initialization should remove the mismatch.

Scope / acceptance

Reproduce the reused-layout case before selecting the implementation.
On file/job identity change, initialize the new job state/links and close the old observer; start at most one observer for a new waiting/running job.
Keep observation and progress intact across Overview/Page/Icon/Share tabs of the same job.
Keep completed/failed/expired and error behavior intact. Do not start Preview workflows during navigation tests.
A possible small solution is a keyed stateful job child component; a key around markup alone would not reset state declared in the parent layout. No cross-view workflow framework is needed.

Source

apps/web/src/routes/admin/piece/[...path]/preview/[jobId]/+layout.svelte — state initialization, captured URLs, onMount/onDestroy and EventSource ownership. Inspected at 34c24f7e4678d9102606de47562ada1bfc16c3d0.

Filed as a separate follow-up discovered during #115; no live jobs, browser verification or implementation performed when filing.

## Problem / evidence The Preview job layout initializes status, errors, phases/logs, tab URLs and its EventSource once. If SvelteKit reuses that layout during direct client-side navigation from job A to job B, the URL/data can belong to B while job-local state, navigation links or observation still belong to A. This predates PR #115: the same initialization/lifecycle is present in its base `7fae03e5bbce7d981fbda08af01b1f97dbefd211`. This is a source-level finding, **not a live browser reproduction or a newly introduced PR regression**. Normal Back to editor → Preview navigation is not the suspect path; switching tabs within the same job should preserve state. ## Reproduction to verify 1. Use two retained, existing Preview jobs A and B; no new jobs are required. 2. Open A, then follow an internal same-origin link directly to B so navigation is client-side. Pasting B into the address bar reloads the app and is not this test. The current UI has no ordinary job-switch control; a temporary developer-inserted anchor is sufficient for investigation. 3. Check that B is in the address bar, then inspect tab hrefs, status, phases/logs and any open progress stream. Suspected failure: A's links/state/subscription persist. 4. Reload B and compare; fresh initialization should remove the mismatch. ## Scope / acceptance - Reproduce the reused-layout case before selecting the implementation. - On file/job identity change, initialize the new job state/links and close the old observer; start at most one observer for a new waiting/running job. - Keep observation and progress intact across Overview/Page/Icon/Share tabs of the same job. - Keep completed/failed/expired and error behavior intact. Do not start Preview workflows during navigation tests. - A possible small solution is a keyed **stateful job child component**; a key around markup alone would not reset state declared in the parent layout. No cross-view workflow framework is needed. ## Source `apps/web/src/routes/admin/piece/[...path]/preview/[jobId]/+layout.svelte` — state initialization, captured URLs, `onMount`/`onDestroy` and EventSource ownership. Inspected at `34c24f7e4678d9102606de47562ada1bfc16c3d0`. Filed as a separate follow-up discovered during #115; no live jobs, browser verification or implementation performed when filing.

~~eleith-gitea-agent Bot referenced this issue 2026-10-16 22:53:44 +00:00~~

Piece viewer — incremental review #115

eleith-gitea-agent Bot referenced a pull request that will close this issue

2026-10-17 00:39:59 +00:00

[web] fix Preview job switching and attachment downloads #119

eleith closed this issue

2026-10-17 01:01:07 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: eleith/luzzle#116