[api] Add option to collect timing info#4512
Conversation
andrewbranch
commented
Jul 1, 2026
There was a problem hiding this comment.
Pull request overview
Adds an opt-in per-request timing/transfer measurement facility to the native API surface, allowing clients to collect round-trip latency, bytes sent/received, and server processing time (when available) and retrieve it via getTimingInfo().
Changes:
- Add server-side timing collection plumbing, emitting server processing time over MessagePack (footer) and JSON-RPC (result envelope).
- Add client-side timing aggregation/exposure (
getTimingInfo,resetTimingInfo) for both sync and async native-preview clients, plus acollectTimingoption and--timingflag. - Add protocol- and integration-level tests covering timing metadata and aggregation.
Reviewed changes
Copilot reviewed 17 out of 17 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| internal/api/server.go | Adds CollectTiming option and wires it into conn setup. |
| internal/api/protocol.go | Introduces serverTimedResult + helpers for timing metadata propagation. |
| internal/api/protocol_msgpack.go | Appends a 4-byte timing footer to MessagePack responses when enabled. |
| internal/api/protocol_jsonrpc.go | Wraps JSON-RPC results in a timing envelope when enabled. |
| internal/api/conn_sync.go | Measures request duration and attaches timing metadata to successful responses. |
| internal/api/conn_async.go | Measures request duration and attaches timing metadata to successful responses. |
| internal/api/protocol_msgpack_timing_test.go | Adds tests for footer/envelope behavior and duration clamping. |
| cmd/tsgo/api.go | Adds --timing flag to enable server timing metadata. |
| _packages/native-preview/src/api/options.ts | Adds collectTiming option for spawned clients. |
| _packages/native-preview/src/api/timing.ts | Implements client-side timing collector/types. |
| _packages/native-preview/src/api/syncChannel.ts | Strips MessagePack timing footer and tracks per-request byte/timing fields. |
| _packages/native-preview/src/api/sync/client.ts | Records per-request timings and exposes get/reset APIs (sync). |
| _packages/native-preview/src/api/sync/api.ts | Re-exports timing types and exposes API-level get/reset (sync). |
| _packages/native-preview/src/api/async/client.ts | Records per-request timings via JSON-RPC envelope and exposes get/reset APIs (async). |
| _packages/native-preview/src/api/async/api.ts | Re-exports timing types and exposes API-level get/reset (async). |
| _packages/native-preview/test/sync/api.test.ts | Adds sync integration tests for timing collection behavior. |
| _packages/native-preview/test/async/api.test.ts | Adds async integration tests for timing collection behavior. |
jakebailey
left a comment
There was a problem hiding this comment.
This seems a little funky; we can't just collect this info out of band and then query it, rather than framing every message differently? It's probably okay, just thinking about it long term
|
That would work, yeah. I wasn't too happy with changing the shape of the JSON-RPC messages, but it didn't end up being much code, and I think I want to replace JSON-RPC eventually here (going in and out of base64 for binary is a little expensive). |
|
I think your suggestion is ultimately simpler, though probably a slight increase in LOC. Let me try it and see. |
|
I had the idea this morning to add some client-side timing info on cumulative RemoteNode materialization from source file buffers, so I'm throwing that together. |
|
Per-node materialization is too fast to measure very well, but we can at least see how many source files were fetched, how many nodes that represents, and how many of those nodes were ever materialized. |