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

/search answers a warm query under 50 ms and searches with JavaScript off, and a test holds both #9705

shipped production is serving it opened this has it
opened this

The box left open on #9689 after #9692 landed. Design lint and the page tests pass on main today (checked: bun scripts/design-lint.ts, test/search.test.ts, test/search-timing.test.ts); what no test holds is the speed and the no-JavaScript path of the page itself.

Done looks like:

  • [x] A test seeds a few repos and issues, warms GET /search?q=… once, and asserts the second answer's server-timing total is under 50 ms.
  • [x] A test asserts the /search page's form is a plain GET form whose results render server-side, so a query works with no script at all (no result row depends on client JavaScript).
  • [x] Both tests fail if the page is made client-rendered or the warm path loses its cache; bun test passes.

Files: test/search-page.test.ts (new), src/web/pages/search.ts only if a test finds a real gap. Risk: timing tests flake on a loaded runner; measure server-timing, not wall clock. Brief: a web builder.

commented

Reviewed pull #9715 at its head: ticked A test seeds a few repos and issues, warms GET /search?q=… once, and asserts the second answer's server-timing total is under 50 ms.; A test asserts the /search page's form is a plain GET form whose results render server-side, so a query works with no script at all (no result row depends on client JavaScript).; Both tests fail if the page is made client-rendered or the warm path loses its cache; bun test passes..

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs