Repository navigation
cell: Server-Timing laps on a chat's creation and first open - #1027
Conversation
A new chat takes 1.8 s in `POST /api/fragments` and nothing says where. Each step of the create, the agent's join, the frame's sign-in token redemption and the `__live` accept now reports its wait in the standard `Server-Timing` header (`<part>;dur=<ms>`), from the `js::Laps` the cell already keeps. Nothing changes behaviour; the e2e lanes check each route names its parts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
futurepaul
left a comment
There was a problem hiding this comment.
Codex review @ 8fb2695: PASS
Checked the affected awaits and error paths: the stamps preserve statuses, bodies, redirect cookies/Location and the 101 WebSocket handle, merge the router/object timings, and leave cached assets untouched. Header values contain only fixed step names and numeric durations, with no identities, names or secrets. The exact-head release build passed at 6,519,278 bytes (80,722 bytes of headroom), and the e2e crate's host unit tests passed (56 passed, one ignored); I did not rerun e2e lanes, and CI check is still running.
alexlwn123
left a comment
There was a problem hiding this comment.
Pass — no blocking defects found at 8fb26953309b2de2920c1cab85911ce7bfdc8fc4. Posting COMMENT under the review automation's policy.
Traced creation (including name retries and agent membership), member updates, sign-in redemption, and live acceptance. The timing stamps preserve existing statuses, bodies, redirect cookies/Location and WebSocket handles; router timings are combined with the object's header. The additional timing-test socket publishes no presence, so it does not disturb the existing presence assertions.
Validation on an isolated exact-head checkout:
cargo test --locked -p fragment-e2e -- --skip hosted::tests: 34 passed, 0 failed, 1 Chrome test ignored, 22 hosted-module tests filtered out. This exercises host unit tests and local HTTP fixtures, not the integration lanes. The hosted module was excluded because this environment documents proxy-denied synthetic recorder hosts.- In
cell/,CARGO_ENCODED_RUSTFLAGS='-Ctarget-feature=+simd128' cargo clippy --locked --target wasm32-unknown-unknown -- -D warnings: passed. - CI
checkpassed. The PR's greene2echeck is a pass-through; its actual shards were skipped.
No real workerd/Cloudflare, container or browser execution was performed in this review. The environment documents unresolved Docker DNS/CA and Chromium sandbox prerequisites; those layers remain unverified. No external vendor services were exercised, and no sandbox/network checks were weakened.
First of the new-chat batch. A new chat waits 1.8 s on
POST /api/fragments(80% of the 3.5 s to usable on preview, bench run eb7234c3b3), and nothing says which step takes it. This PR only measures; nothing changes behaviour.Each route reports its waits in the standard
Server-Timingheader,<part>;dur=<ms>, using thejs::Lapsthe cell already keeps. That costs one header per response.POST /api/fragments:ledger,object, andagentfor an agent's create;repo,key,manifest,list,seedandalarm, merged into the same header.PUT /api/f/<name>/members/<agent>:identity,list,joined.__signin?token=(the frame's sign-in):redeem.__liveaccept:identity,accept.docs/api.mdnames the parts. The e2e lanescontrol,members,framesandlivecheck that each route sends its parts.Tests:
cargo xtask checkpasses.cargo xtask e2e --only auth,create,lockdown,members,reach,frames,live,channels,chat,signin,shell,watch,sharegave 898 passed, 0 failed.Once this is on preview, I'll rerun the chat bench and report the split.
🤖 Generated with Claude Code