You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: address review findings on the Telemetry API implementation
Four problems, all reachable in normal use:
Delivery used http.DefaultClient, which has no timeout. Batches that reach a
size limit are delivered on the goroutine producing the event, so a subscriber
that accepted a connection and never answered would stall the sandbox's event
pipeline. Delivery now uses a client that gives up.
platform.report was emitted with status success unconditionally, including from
the invoke-timeout path, so a timed-out invocation was reported as a successful
one -- the opposite of what an extension watching that field needs. The status
is now threaded through.
The report's memory metrics were serialized as JSON strings, because the memory
size arrives as one. The Telemetry API defines them as numbers, and a consumer
decoding into a typed struct rejects strings. They are parsed now, and the
report also carries initDurationMs on a cold start, as a real function's does.
Dispatch decided whether to buffer or deliver in one lock section and acted in
another. A Subscribe interleaving between the two would insert itself, replay a
copy of the buffer that did not yet hold the event, and leave the event buffered
for nobody -- precisely the ordering the buffer exists to handle. The decision
now happens under a single held lock.
Tests cover the timeout, the status, the numeric metrics and the cold-start
figure. The lost-event window is not covered: the two lock sections it needed to
interleave between were adjacent and 400 attempts never hit it, so that fix
rests on reading the code rather than on a failing test.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments