Should channels external to Node.js be autoinstrumented? #25

Activity

1. legendecas commented on Nov 3, 2026

   

   legendecas

   on Nov 3, 2026

   Last edited by legendecas

   Member

   More actions

   I'm considering this with #29 together.

   AsyncLocalStorage and diagnostics_channel provide general mechanism APIs for propagating context and publishing diagnostic events. But there is no API contract on the AsyncLocalStorage values and diagnostics channel messages, like a Trace Context AsyncLocalStorage, or a contracted type of the channel messages.

   OpenTelemetry establishes the contract through a context API. For example, it stores a mutable RPCMetadata object in its context, which framework instrumentations such as Express and Koa update with routing information. #29 illustrates another part of this problem: the integration needed to share context between microtel and OpenTelemetry, and maybe other libraries.

   In TC39's AsyncContext work, implementers have expressed interest in a similar idea: web-platform APIs could use built-in context variables for purposes such as task attribution. These variables would not necessarily be exposed directly. Instead, platform APIs could provide access with semantics appropriate to their use case.

   Since microtel already uses W3C Trace Context, I'm wondering could it provide a similarly scoped, strongly typed microtel.context API backed by an internal AsyncLocalStorage?

   Conceptually, this API would expose strongly typed:

   • W3C Trace Context fields.
   • A closed set of contextual metadata fields, such as RPC routing information, accessed through dedicated getters and setters, that are protocol/framework agnostic.
   • Structured baggage access using the W3C Baggage wire format, with mutation semantics like OpenTelemetry Baggage API, which provides a semantic subset of W3C Baggage (e.g. no dup keys). microtel already propagates the baggage headers in opaque but it does not have a getter/setter yet.

   There would be no generic string-keyed metadata getter/setter. Each supported field would have an explicit contract covering its meaning, type, ownership, scope, and mutation behavior. Libraries needing arbitrary context values should continue using their own ALS.

   I would imagine that OpenTelemetry could integrate with this shared context for trace identity, baggage, and supported metadata while retaining its own ALS for the rest of Otel Context API features. Its context integration would coordinate both stores, preserving existing OTel APIs and instrumentation.

   The intended scope would be context access, propagation, and narrowly defined metadata like route information.

   👍React with 👍2Reacted by Abhijeet Prasad and Daniel Dyla
2. AbhiPrasad commented on Nov 3, 2026

   

   AbhiPrasad

   on Nov 3, 2026

   Member

   More actions

   Having microtel own a context api seems like the right direction!
3. dyladan commented on Nov 4, 2026

   

   dyladan

   on Nov 4, 2026

   More actions

   A closed set of contextual metadata fields

   Is this for passing data that would be attached to telemetry, or is it for accessing the underlying telemetry objects like getting the current span?
4. legendecas commented on Nov 5, 2026

   

   legendecas

   on Nov 5, 2026

   Member

   More actions

   Is this for passing data that would be attached to telemetry, or is it for accessing the underlying telemetry objects like getting the current span?

   I would scope this to telemetry metadata like W3C Trace Context, RPC metadata, Baggages.

   For now, there is no public "telemetry objects" API yet in microtel. I would keep this as an vision where we see how OpenTelemetry API integrates with Node.js.