Skip to content

cell: Server-Timing laps on a chat's creation and first open - #1027

Merged
futurepaul merged 1 commit into
masterfrom
claude/create-server-timing
Nov 4, 2026
Merged

futurepaul merged 1 commit into
masterfrom
claude/create-server-timing

Conversation

@futurepaul

Copy link
Copy Markdown
Collaborator

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-Timing header, <part>;dur=<ms>, using the js::Laps the cell already keeps. That costs one header per response.

  • POST /api/fragments:
    • ledger, object, and agent for an agent's create;
    • then the Fragment object's own repo, key, manifest, list, seed and alarm, merged into the same header.
  • PUT /api/f/<name>/members/<agent>: identity, list, joined.
  • __signin?token= (the frame's sign-in): redeem.
  • __live accept: identity, accept.

docs/api.md names the parts. The e2e lanes control, members, frames and live check that each route sends its parts.

Tests: cargo xtask check passes. cargo xtask e2e --only auth,create,lockdown,members,reach,frames,live,channels,chat,signin,shell,watch,share gave 898 passed, 0 failed.

Once this is on preview, I'll rerun the chat bench and report the split.

🤖 Generated with Claude Code

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 futurepaul left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 alexlwn123 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 check passed. The PR's green e2e check 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.

@futurepaul
futurepaul added this pull request to the merge queue Nov 4, 2026
Merged via the queue into master with commit bcc50fc Nov 4, 2026
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants