Is context-zone required for a working context on a Browser environment?

[niekert]

Hi,

This is my first time implementing opentelemetry and I'm really impressed with the project. I'm looking to instrument fetch calls and some user interaction in a browser environment with B3 propagation. Managed to succesfully instrument individual fetch calls and propagating B3 headers. Also I added some some spans that start on click and end when something loaded.

Ideally I'll have the auto instrumented fetch spans as child spans of the trace that starts when I click something and ends when what I want is visible. If I am understanding correctly this scenario is what the context.with and setSpan APIs are intended for. But by default the context is a noop context so it will not do anything.

If I'm understanding correctly context-zone is required for correctly tracking async tracing context in a browser env and is the only available context for a browser env atm. Sadly zone-js breaks our application (React+apollo, I believe due to some API not being patched correctly) and the extensive monkey patching in zone.js and that it breaks our application makes me cautious to use it.

Because the main use case is Starting a single trace at some point in time, auto-instrumenting all fetch requests inbetween, and ending the trace after I am wondering if there would be a way to get away with a more naive context implementation. Perhaps where only a single parent span can be stored on the context at the same time?

Looking at an alternative tracing implementations (sentry JS) I noticed a different APIs exists for starting a parent trace (called transaction) and child spans on it. I was experimenting with implementing a similar approach as an abstraction on openTelemetry API, but due to the parent or getActiveSpan APIs being removed I don't immediately see a way for it without using a context. But I am unsure about this approach or the topic in general so any thoughts are appreciated.

I'm also wondering if there is any standardizing happening around zones or an alternative to the challenge it is trying to solve? Seems like a native API could be something that is worth standardizing but I noticed the TC39 proposal has been withdrawn.

[Flarna]

There is no special context manager required in general. You can always pass around the context object manually if this fits your usecase.

e.g. if you look at Tracer.startSpan() it has and optional third argument context. If you don't pass anything api.context.active() is used but if you have your favorite context object available you can use it.

Be aware that the NoopContextManager (used if you don't specify anything special either direct or via TracerProvider options) is quite Noop - active() will always return ROOT_CONTEXT.

It's not that hard to implement a simple context manager which has at least some basic functionality for sync calls but "breaks" on async:

class SimpleContextManager extends NoopContextManager {
  active(): Context {
    return this._activeContext;
  }

  with<A extends unknown[], F extends (...args: A) => ReturnType<F>>(
    context: Context,
    fn: F,
    thisArg?: ThisParameterType<F>,
    ...args: A
  ): ReturnType<F> {
    const prevContext = this._activeContext;
    try {
      this._activeContext = context;
      return fn.call(thisArg, ...args);
    } finally {
      this._activeContext = prevContext;
    }
  }

  private _activeContext = ROOT_CONTEXT;
}

But once you want to use instrumentations besides OtelApi calls direct from your code it may be hard. You can't specify the context object used within these instrumentations. They will pick up the context using api.context.active() and they may rely on the context manager in use to support context passing across async calls.

Edit: Just found that @opentelemetry/web exports a StackContextManager which is like above but supports also bind so it's a preferred solution.

[niekert]

Thank you for that explanation, makes sense to me now 👍 Context-zone seems required on the web for context across async calls but now makes sense to me why. Wish something like async_hooks would exist in the browser to avoid the zone-js monkey patching, hopefully there can be a standard for it some day

[vmarchaud]

To add about the async_hooks system in web, it's currently a proposal for the TC39 (however there was multiple proposal in the past that never made it in JS spec), you can find more history here too.

[Nighttraveler]

Hey @niekert were you able to achieve this? I'm in a similar situacion we create a span our self and we want that the spans that FetchInstrumentation creates, attaches to the one we create, but we don't have success so far with it

[elsonz]

I still have so much confusions about the usage scenario of Context-zone that it manages context across async calls. It seems that StackContextManager is enough. So, I was wondering that if you could make an example that the Context-zone is required.