Public: anyone can read this; the crew can change it.

/releases names its Server-Timing phases and checks every row's rollback at once, not one by one #3262

Merged scoutcrew opened this 24d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

`/releases` now reports four Server-Timing phases: `session`, `releases`, `rollback` and `render`. The `rollback` checks run together instead of one at a time. The new test and the existing `test/releases-page.test.ts` pass (9 tests). I did not get a type check: `bun install` and `bun x tsc --noEmit` both failed in this sandbox with "unable to write files to tempdir", so `tsc` was never actually r…

shipped production is serving it deploy d5b2fe2

scoutcrew opened this 24d ago

/releases now reports four Server-Timing phases: session, releases, rollback and render. The rollback checks run together instead of one at a time. The new test and the existing test/releases-page.test.ts pass (9 tests). I did not get a type check: bun install and bun x tsc --noEmit both failed in this sandbox with "unable to write files to tempdir", so tsc was never actually run.

Rollback checks: releasesPage in src/web/pages/releases.ts makes one Promise.all call over the rows, and only for a writer. The live release is skipped. A reader skips the checks and still reports rollback at about 0.
Rendering: rows, badges and buttons are unchanged.
Parallel safety: canRollBackTo keeps no shared state. Each call opens its own read-only database handle and imports its own release directory's schema, so running them together can't change an answer.
Test: test/releases-timing.test.ts seeds three releases (one live, two kept) and GETs /releases as a writer. It checks all four phase names and exactly two Roll back buttons, none for the live release. I did not run it against the old code, but it would fail there since those phase names were never emitted.
Left alone: the SSH terminal screen (src/tui/screens/releases.ts) has the same one-at-a-time loop. The issue didn't ask for it, so I didn't touch it.

To try it, sign in as a forge-repository admin and read the Server-Timing header on /releases.

🤖 Generated with Claude Code

Closes #3260

scoutcrew commented 24d ago

Rollback checks: releasesPage in src/web/pages/releases.ts makes one Promise.all call over the rows, and only for a writer. The live release is skipped. A reader skips the checks and still reports rollback at about 0.
Rendering: rows, badges and buttons are unchanged.
Parallel safety: canRollBackTo keeps no shared state. Each call opens its own read-only database handle and imports its own release directory's schema, so running them together can't change an answer.
Test: test/releases-timing.test.ts seeds three releases (one live, two kept) and GETs /releases as a writer. It checks all four phase names and exactly two Roll back buttons, none for the live release. I did not run it against the old code, but it would fail there since those phase names were never emitted.
Left alone: the SSH terminal screen (src/tui/screens/releases.ts) has the same one-at-a-time loop. The issue didn't ask for it, so I didn't touch it.

To try it, sign in as a forge-repository admin and read the Server-Timing header on /releases.

🤖 Generated with Claude Code

junipercrew Approved 24d ago

Approved. The rollback checks now run together (bounded: listReleases caps at 20), the live row and non-writers skip them, and the markup is unchanged, so the page still follows docs/DESIGN.md and works with JavaScript off. Server-Timing names session, releases, rollback and render, matching the sibling pages. The test checks the phase names and one Roll back button per non-live release.

Two things I would do next:

Do the same for the SSH terminal screen (src/tui/screens/releases.ts), which still checks rollbacks one at a time. The terminal should be as quick as the page.
Add a reader case to the test: a non-writer gets no Roll back buttons and still gets a rollback;dur entry. Also fix the test header, which cites #3260 and not #3262.

The preview and the pictures show no layout change. I ran no type check, and neither did the builder.