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

A repository's tell page's Server-Timing names its phases: session, each read, render #3538

Merged opened this

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

Merged

`GET /:owner/:name/tell` now sends a Server-Timing header with `session`, `repo`, `access` and `render` phases, written the same way `src/web/pages/milestones.ts` does it. The new test and the existing tell-toolbar test pass. The type check did not run: `bun x tsc --noEmit` failed here with "bun is unable to write files to tempdir: ReadOnlyFileSystem". I pushed anyway, so the forge's check is the…

shipped production is serving it deploy a9b30ef

opened this

GET /:owner/:name/tell now sends a Server-Timing header with session, repo, access and render phases, written the same way src/web/pages/milestones.ts does it. The new test and the existing tell-toolbar test pass. The type check did not run: bun x tsc --noEmit failed here with "bun is unable to write files to tempdir: ReadOnlyFileSystem". I pushed anyway, so the forge's check is the first type check this change gets.

  • Phases: session is the time the server already spent on the session. repo is loadRepo. access is mayDirectCrew, the page's only other read. render covers the composer and the page or fragment, and it is also set for ?in=place.
  • Unchanged: the body, status codes and caching, and the order and errors of the wrapped reads. The not-found and sign-in-first early returns are as before.
  • Left out: those early returns send no render phase, because nothing is rendered. Milestones behaves the same way. No other page is touched.
  • Test: test/tell-here-timing.test.ts requests the page and ?in=place and checks each phase name has a duration. It checks names only, never a wall-clock time.

To try it, sign in, then run curl -sI -b <cookie> https://<host>/<owner>/<name>/tell and read server-timing.

🤖 Generated with Claude Code

Closes #3508

commented

GET /:owner/:name/tell now sends a Server-Timing header with session, repo, access and render phases, written the same way src/web/pages/milestones.ts does it. The new test and the existing tell-toolbar test pass. The type check did not run: bun x tsc --noEmit failed here with "bun is unable to write files to tempdir: ReadOnlyFileSystem". I pushed anyway, so the forge's check is the first type check this change gets.

  • Phases: session is the time the server already spent on the session. repo is loadRepo. access is mayDirectCrew, the page's only other read. render covers the composer and the page or fragment, and it is also set for ?in=place.
  • Unchanged: the body, status codes and caching, and the order and errors of the wrapped reads. The not-found and sign-in-first early returns are as before.
  • Left out: those early returns send no render phase, because nothing is rendered. Milestones behaves the same way. No other page is touched.
  • Test: test/tell-here-timing.test.ts requests the page and ?in=place and checks each phase name has a duration. It checks names only, never a wall-clock time.

To try it, sign in, then run curl -sI -b <cookie> https://<host>/<owner>/<name>/tell and read server-timing.

🤖 Generated with Claude Code

Approved

Matches the milestones pattern exactly: session, repo, access, render phases; no markup, status, caching or security behaviour changes, so the design system is untouched. The test covers the page and ?in=place and checks names only. Next: (1) the test header cites #3508 while the pull is #3538, so fix the reference; (2) the early returns (not found, sign-in) send no render phase, which is fine, but a one-line note in the module doc would save the next reader a question.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs