users usually install packages with the latest tag which is the default for npm and yarn:

npm install @opentelemetry/node @opentelemetry/api
yarn add @opentelemetry/node @opentelemetry/api

Currently, user will get incompatible versions as latest core packages has peer dependency on ^1.0.0-rc.0 (or 1.0.0-rc.0 after this PR), but api npm latest points to 0.18.1.
So a user creating a fresh installation will have to run something like:

yarn add @opentelemetry/node @opentelemetry/[email protected]

which can be missed very easily and create confusions.

I suggest making the default versioning consistent between core and api packages, by publishing rc.0 version as "latest" in npm if it is possible

Currently NoopContextManager.active() always returns ROOT_CONTEXT.

This is somewhat strange if you consider following code as it looks like a basic contract is broken:

api.context.with(ctx, () => {
  api.context.active() // returns ROOT_CONTEXT
});

I think even the NoopContextManager should at least fulfill the basic contract that context.active() within the with() callback returns the context set.

In special if I think about Behavior of the API in the absence of an installed SDK a typical piece of code could be something like this (only a propagator installed but no SDK):

const ctx = api.propagation.extract(ROOT_CONTEXT, carrier);
api.context.with(ctx, () => {
  ...
  api.propagation.inject(api.context.active(), carrier);
});

Or is this the intended setup and a user has to create/install a working context manager in addition to the propagator in such setups?

Hi folks! I was wondering if there are ways to detect at runtime whether tracing is enabled / configured. our only dependency is on @opentelemetry/api

I can think of a few ways:

• create a span and check if it's recording
• create a span and check if spanContext is valid

But I was wondering if there's an api for checking whether a global tracer provider has been configured by the user at runtime without creating a span?

Context here is we'd like some way to short-circuit tracing operations unless the customer has enabled tracing. I know the API does a great job at providing no-op implementations if nothing is configured but we have our own logic that we'd love to bypass.

Any other options here?

Thanks!

With the following configuration:

import { HttpInstrumentation } from '@opentelemetry/instrumentation-http';
import { propagation } from '@opentelemetry/api';
import { HttpTraceContext } from '@opentelemetry/core';
import { NodeTracerProvider } from '@opentelemetry/node';
import { SimpleSpanProcessor, ConsoleSpanExporter } from '@opentelemetry/tracing';

const tracerProvider = new NodeTracerProvider({});

tracerProvider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));
propagation.setGlobalPropagator(new HttpTraceContext());

tracerProvider.register();
registerInstrumentations({
  tracerProvider: tracerProvider,
  instrumentations: [new HttpInstrumentation()]
});

console.log('tracing initialised');

export const tracer = tracerProvider.getTracer('my-tracer');

in v0.18.1 the snippet below logs the span whereas in the latest version it logs undefined :

const cakeSpan = tracer.startSpan("bake-cake");
context.with(setSpan(context.active(), cakeSpan), () => {
  console.log(getSpan(context.active()));
});
cakeSpan.end();

As of now these interfaces are in @opentelemetry/api and implementation are part of @opentelemetry/core. Ideally they should have been in base sdk.

Span.addEvent() does not use these types, so it may be worth hiding them (or exposing them in the SDK level, in case they are used around there).

Also, as all events are expected to have a timestamp, maybe a single class could have all of this.

That is, that it is accessed through opentelemetry.trace instead of opentelemetry - which is followed by other SIGs, as the idea is overall having each concern have exclusive logical access to its own key/slot. Likewise for the Baggage portion.

Not a strong feeling though, as things are slightly differently organized for JS. For your consideration.

I am using this library through @azure/identity and is throwing a Circular dependency warning. I have placed the text warning and picture.

I am importing @azure libraries as:
import * as azureIdentity from '@azure/identity';
import * as appConfig from '@azure/app-configuration';

Warning:
Circular dependency: node_modules\@azure\identity\node_modules\@opentelemetry\api\build\src\index.js -> node_modules\@azure\inode_modules\@opentelemetry\api\build\src\internal\global-utils.js -> node_modules\@azure\identity\node_modules\@opentelemetr Circular dependency: node_modules\@azure\identity\node_modules\@opentelemetry\api\build\src\index.js -> node_modules\@azure\inode_modules\@opentelemetry\api\build\src\internal\global-utils.js -> C:\Users\JBlanco\Documents\MFE - Product\node_modules\\@azure\identity\node_modules\@opentelemetry\api\build\src\index.js Circular dependency: node_modules\@azure\core-http\node_modules\@opentelemetry\api\build\src\index.js -> node_modules\@azure\tp\node_modules\@opentelemetry\api\build\src\internal\global-utils.js -> node_modules\@azure\core-http\node_modules\@opentele Circular dependency: node_modules\@azure\core-http\node_modules\@opentelemetry\api\build\src\index.js -> node_modules\@azure\tp\node_modules\@opentelemetry\api\build\src\internal\global-utils.js -> C:\Users\JBlanco\Documents\MFE - Product\node_modulules\@azure\core-http\node_modules\@opentelemetry\api\build\src\index.js

Any other information needed please let me know.

/**

• Store a baggage in the given context
• @param {Context} Context that manage all context values
• @param {Baggage} baggage that will be set in the actual context
  */
  export function setBaggage(context: Context, baggage: Baggage): Context {
  return context.setValue(BAGGAGE_KEY, baggage);
  }

seems like setbaggage creates a new context when it should not ?

Is it sufficient to put on the README for the API that 0.18 is the release candidate? Or do we want to release something like 1.0.0-rc.1?

Originally posted by @dyladan in open-telemetry/opentelemetry-js#1982 (comment)

The NOOP implementations are currently exported. Particularly the NOOP tracer is used to create NOOP spans. After #51, this will no longer be required. Because the specification does not say to export NOOP implementations, we should remove their exports before 1.0

Span attributes (and by extension event attributes) are defined in the js api as

/**
 * Attribute values may be any non-nullish primitive value except an object.
 *
 * null or undefined attribute values are invalid and will result in undefined behavior.
 */
export type AttributeValue =
    | string
    | number
    | boolean
    | Array<null | undefined | string>
    | Array<null | undefined | number>
    | Array<null | undefined | boolean>;

However, the proto defintion is

    // attributes is a collection of attribute key/value pairs on the event.
    // Attribute keys MUST be unique (it is not allowed to have more than one
    // attribute with the same key).
    repeated opentelemetry.proto.common.v1.KeyValue attributes = 3;

With KeyValue defined as taking AnyValue

// KeyValue is a key-value pair that is used to store Span attributes, Link
// attributes, etc.
message KeyValue {
  string key = 1;
  AnyValue value = 2;
}

Which means that attributes for a span / event "should" support nested objects, but the api specification blocks this.

I'm not sure if such issue has been already created, but I couldn't find it.
Because we did major cleanup with plugins and other stuff, we can now go back to namespacing in diag which would give us a better understanding with logs.
I would like to implement following pattern in few places - with instrumentation it will be the easiest.
Each instrumentation calls a constructor with name. We will use this name to create a logger class that will be already namespaced. So in all instrumentations we will just have one protected logger which we will use instead of api.diag.
This way the logs will be transparent and it will look like
this.diag.error('foo')
// will show
// "@opentelemetry/instrumentation-http", "foo"

under the hood those loggers will always be called diag but with one extra param in front of it

and new publicdiag property will be created automatically in constructor.

We can discuss if it should be public or protected, but I would vote for public to be able to call it easily from any subclass etc.

For other things like exporter we can add things after this change to avoid too many changes and overhead.

The first part will update instrumentations in core. After release I will update contrib and meanwhile I believe we can already have agreement towards exporters and anything else that we think should have it.

I don't want to start before I have some thumbs up for it.

This is the recently updated name, instead of NoopSpan or DefaultSpan (alternative option, as per the spec, is to abstract it through a method, i.e. Java exposes it through Span Span.wrap(SpanContext).

Diag logger has a really crucial part while debugging a host - for tracing issues or even a non-related logic issue.
Currently, the logs dumped by the diag logger have no context, we cannot understand if the log arrived from OT or anywhere else.
I guess that we need to label it somehow - a by static label [OpenTelemetry] or custom label for the client choice.

The upgrade guidelines have sections for upgrading:

• from version 0.21.0 to 1.0.0 - makes sense
• from version 0.20.0 to 0.21.0 - also makes sense
• from version 1.0.0-rc.3 to 0.20.0 - this is very confusing

I think now from reading the compatibility matrix that "v1.0.0-rc.3" is genuinely a version number that occurred between 0.18.0 and 0.20.0? If so that's surprising and confusing enough that I feel like it needs to be called out explicitly. As it is, reading the README I thought there was a mistake.

For context I'm currently reading this with an eye to updating code currently using API version 0.18.0 to use API version 1.0.3, and it does indeed break because it looks for api.getSpan in the wrong place. But it took me a while to understand what the upgrade guidelines were telling me.

The specification now uses a common definition of Attributes for traces and metrics. Our definition of attributes should be moved from the trace directory to a common directory to reflect this.

Spec PR ongoing at the time of this issue creation open-telemetry/opentelemetry-specification#1653

While this functionality is not in the spec, we need to remove it from the API. We can create a package in SDK for API extensions, or include it in the instrumentation package, if we want to expose this functionality to instrumentations.

Is this something we can/should improve in API? The main idea was to return Noop instances if version doesn't match but it should not crash nor end up in endless loops.

I believe that it does return NOOP. Our endless loop happened due to the context not being set and read by the same api version, causing not to work - which is a recipe for infinite loops.
There might be other issues such as propagation not working etc, but it will probably resolve when we move to api v.1.0.0 everywhere.

Originally posted by @blumamir in open-telemetry/opentelemetry-js#2055 (comment)

We can prevent this endless loop by returning a suppressed instrumentation context from the noop context manager. If the user is manually tracing without a context manager, then calling context.active() should not be used anyway.

One important caveat to the above is that a call to startSpan will by default grab the active context by default. If this context has instrumentation suppressed then the returned span will be noop. Possibly we could introduce a new constant context similar to ROOT_CONTEXT but which is actually NOOP_CONTEXT (only returned by the noop context manager) which can be used to determine if the context manager is enabled?

What happened?

Around 2:30 PM EST on Tue May 18, we pushed API version 1.0.0-rc.1 which contained breaking changes which were incompatible with 1.0.0-rc.0. Many users, including anyone using the default SDK, depended on the "carat" range ^1.0.0-rc.0 which allowed the upgrade to 1.0.0-rc.1 automatically.

This issue was resolved around 8:00 AM EST on Wed May 19 by pushing a reverted version as 1.0.0-rc.2. For specific mitigation steps, see "What did we do to fix it," below.

What was the impact?

The broken 1.0.0-rc.1 version was downloaded 184 times before it was deprecated on NPM. There is no way to know who these 184 downloads were. Many of them were CI builds, but it is likely that at least some "real" users installed the broken package.

How did this happen?

This was caused by a misunderstanding of the way that semver handles prerelease packages. We were under the mistaken impression that users who depended on "carat" ranges would not receive the next prerelease version without specifically installing it.

To quote the semver documentation:

^1.2.3-beta.2 := >=1.2.3-beta.2 <2.0.0-0 Note that prereleases in the 1.2.3 version will be allowed, if they are greater than or equal to beta.2. So, 1.2.3-beta.4 would be allowed, but 1.2.4-beta.2 would not, because it is a prerelease of a different [major, minor, patch] tuple.

What did we do to fix it?

As JavaScript maintainers, we took the following steps:

1. Release 1.0.0-rc.0 as 1.0.0-rc.2, reverting all changes introduced by 1.0.0-rc.1 for users who depended on ^1.0.0-rc.0 or ~1.0.0-rc.0.
2. Deprecate 1.0.0-rc.1 on NPM

What is the plan moving forward?

1. The code which was released as 1.0.0-rc.1, which contains important fixes and updates, will be released as 0.19.0.
2. Until we release a GA 1.0.0 version, we will stay at 0.x.y, which allows us to push breaking changes as minor version bumps.
3. After 1.0.0 there will be no breaking changes released.

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#wrapping-a-spancontext-in-a-span

Brought up in the spec call

Create a troubleshooting section on the readme which is a little more prominent

The API compatibility version should be replaced with a true semver check. This will be a port of open-telemetry/opentelemetry-js#1772

Maybe we should add deleteSpan(context) (and deleteBaggage(context)) at some time?

Originally posted by @Flarna in open-telemetry/opentelemetry-js#2185 (comment)

The Spec requires that the specified value is used for debugging purposes and does not uniquely identify the key, and it seems Symbol.for() (used by this method) returns the same value for the same string at all times.

Spec v1.4.0 added a new optional parameter to TracerProvider.getTracer, (link).

However, in a similar situation, implementations like https://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/opentelemetry-sdk-metrics-base/src/MeterProvider.ts#L48 may already extending the MeterProvider.getMeter with positional parameters, so adding new positional parameter schemaUrl in @opentelemetry/api-metrics would conflict with those implementations. (Related: open-telemetry/opentelemetry-js#2529)

The good news is that BasicTracerProvider.getTracer in https://github.com/open-telemetry/opentelemetry-js/blob/main/packages/opentelemetry-sdk-trace-base/src/BasicTracerProvider.ts#L93 didn't extend the method with positional parameters. So we can still extend the method with optional positional parameters:

interface TracerProvider {
  getTracer(name: string, version?: string, schemaUrl?: string): Tracer;
}

Still, the approach above leaves us a dilemma when a new optional parameter is added in the future. For better extensibility and to keep compatibility, we can override the function with a variable second parameter type like the following example.

interface TracerProvider {
  getTracer(name: string, version?: string): Tracer;
  getTracer(name: string, options?: TracerOptions): Tracer;
}

It looks like Renovate bot is not active in this repo. At least I can't fine a single PR and we still use e.g. typescript 4.1,...

Besides that I think mayurkale22 should be replaced by @vmarchaud in renovate.json

Pursuant to the community guidelines, a vote of the maintainers is required to resolve #78.

Should the context method bind require an explicit context argument or use context.active() as default?

Tracing instrumentation needs to be enhanced in the community demo in preparation for the v1 release.

Referencing issue:
open-telemetry/opentelemetry-demo#53

Not sure if this ought to be labelled a "bug" or "discussion". I noticed a discrepancy between span.recordException and the spec

Specifically, this part (current implementation does not allow passing additional attributes):

If RecordException is provided, the method MUST accept an optional parameter to provide any additional event attributes (this SHOULD be done in the same way as for the AddEvent method). If attributes with the same name would be generated by the method already, the additional attributes take precedence.

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

Today, the way we document getting the current span is to pass in the active context to getSpan:

const currentSpan = opentelemetry.trace.getSpan(opentelemetry.context.active());

Conceptually, this is seen as one operation, but it's actually two (get the active context, then get the span from that).

Some feedback I've seen from otel-js users is that it'd be nice if they could have a special case API, perhaps like this:

const currentSpan = opentelemetry.trace.getCurrentSpan();

I think it's quite common to want whatever the current span is and then do something with it, but less common to want an arbitrary span from an arbitrary context. My interpretation of the spec is that this should be allowable. If so, the getCurrentSpan function would be my initial preference, but really anything that shortens the code and requires a single operation, rather than the current 2 operations.

What do you think?

setGlobalTracerProvider() sets the new TracerProvider as delegate in it's ProxyTracerProvider even if setting it as global fails.

Not sure if this is intended but I think we should first call registerGlobal and only if it returns true we should set it as delegate.

see

Add method to get all spans associated with current trace.

Potential API:

const opentelemetryApi = require('@opentelemetry/api');

// Probably not feasible to keep track of all spans forever and allow getting spans for any traceId
const spans = opentelemetryApi.trace.getSpansForTrace(traceId);

// So only keep track of the spans for the current trace
const spans = opentelemetryApi.trace.getSpansForCurrentTrace();

The current active context has a span associated with it and each span is associated with a trace by traceId. You can get the current traceId via this little snippet:

const opentelemetryApi = require('@opentelemetry/api');

const activeCtx = opentelemetryApi.context.active();
const span = opentelemetryApi.trace.getSpan(activeCtx);
const traceId = span.spanContext().traceId;

But there is no way to get the rest of the spans associated with that trace or navigate the DAG of spans. If I have the root span, I don't see a way to navigate down the DAG for the child spans since they have child -> parent relationship by parentSpanId (and their traceId).

To accomplish getting all spans for a trace with the API today, I created a SpanProcessor which has access to all spans coming through and it keeps track of all of the spans associated with the trace for the lifetime of an Express route (handled via an Express middleware), https://stackoverflow.com/questions/72973140/get-all-child-spans-associated-with-opentelemetry-trace/73058566

All of this is pretty cumbersome though. It seems like a sane default to keep around the spans for the trace that corresponds to the current active context. The spans can be garbage collected when the active context is no longer in scope.

For a use case, my goal is to add a performance bar to the top of the page served to the client that shows off the slow API requests that happened in the backend. I would like to pull and re-use the data from the OpenTelemetry spans/traces.

This is probably not a big issue. The current setGlobalPropagator and getGlobalPropagator only accept the TextMapPropagator type but it is possible that there can be other propagator types such as binary propagator. We can introduce the new global set/get methods for new propagator types to solve that problem. It would be nice if the names are more explicit to indicate what they do setGlobalPropagator -> setGlobalTextMapPropagator and getGlobalPropagator -> getGlobalTextMapPropagator.

Context 🧠

I'm working to convert some TypeScript code from being instrumented with Datadog dd-trace to OpenTelemetry. I'm finding the tracing API not very friendly or straightforward because of the need to manually end() spans. I read through the discussion at open-telemetry/opentelemetry-js#1923 which highlighted that implementation in other languages (such as Ruby) don't have this issue.

With dd-trace, once things are initialised then I can easily manually instrument as follows:

tracer.trace(
    "event",
    (span) => {
      // do stuff
    }
  );

As part of that API I get this useful behaviour based on the execution of the wrapped callback:

The span will automatically be finished when one of these conditions is met:

• The function returns a promise, in which case the span will finish when the promise is resolved or rejected.
• The function takes a callback as its second parameter, in which case the span will finish when that callback is called.
• The function doesn't accept a callback and doesn't return a promise, in which case the span will finish at the end of the function execution.

Question ❓

OpenTelemetry is providing me with tracer.startActiveSpan but I don't understand why the responsibility is left with me to end the resulting span. For most cases, isn't it reasonable to assume that once the callback context ends I want the span to end? And if it throws to mark the span with the error? Otherwise why the callback-style API?

I'm finding myself writing a trace wrapper to make the API workable and apply boilerplate such as error handling to close spans as errors etc. and I don't know why I need to?

// something like follows
(tracer as any).trace = (
  name: string,
  fn: (span: opentelemetry.Span) => unknown
) => {
  return tracer.startActiveSpan(name, async (span) => {
    try {
      await Promise.resolve(fn(span));
      span.setStatus({
        code: opentelemetry.SpanStatusCode.OK,
      });
    } catch (e) {
      const err = e as Error;
      span.recordException(err);
      span.setStatus({
        code: opentelemetry.SpanStatusCode.ERROR,
        message: err.message,
      });
      throw err;
    } finally {
      span.end();
    }
  });
};

Problem 1: just setting the logger uses a default level instead of the one from env configuration (https://github.com/open-telemetry/opentelemetry-js-api/blob/main/src/api/diag.ts#L75). Which means when setting a logger you need to fetch the ENV variable by yourself

diag.setLogger(new DiagConsoleLogger(), getEnv().OTEL_LOG_LEVEL);

which sort of defeats the point of the ENV variable?

Problem 2: tangentially, after setLogLevel was removed, there's no way to set the level and the logger independently (#9), which will make integration with Node ENV configuration tricky.

I'd propose:

• reviving setLogLevel
• change setLogger so that second argument, unless provided, doesn't change the log level
• allow setLogLevel and setLogger to be called in any order

Also, I'm happy to hear your thoughts, and send a PR when a resolution is decided.

ping @dyladan

It would be useful to get an AMD/Require source option available in NPM form to avoid a transpilation step for developers. If we provide a dev framework that supports AMD that adds OT as a dependency, they won't be able to use that dependency without manually transpiling.

As far as I can tell the only (typescript safe) way to link spans is to pass the link when creating the span as here: https://open-telemetry.github.io/opentelemetry-js-api/interfaces/tracer.html#startspan

However, it's desirable in many situations to be able to associate spans after they are created. I couldn't find any way to do this.

I would expect to be able to do something like:

span.link(otherSpanContext)

If there's a way to do this already please let me know. I could contribute this if it makes sense

Hi friends,

We are working with aws-otel-nodejs-amd64-ver-1-0-1 and currently it generate this error

2022-02-25T16:50:46.804Z undefined ERROR Error: @opentelemetry/api: Attempted duplicate registration of API: propagation at Object.registerGlobal (/opt/nodejs/node_modules/@opentelemetry/api/build/src/internal/global-utils.js:33:19) at PropagationAPI.setGlobalPropagator (/opt/nodejs/node_modules/@opentelemetry/api/build/src/api/propagation.js:51:31) at NodeTracerProvider.register (/opt/nodejs/node_modules/@opentelemetry/sdk-trace-base/build/src/BasicTracerProvider.js:99:31) at NodeTracerProvider.register (/opt/nodejs/node_modules/@opentelemetry/sdk-trace-node/build/src/NodeTracerProvider.js:28:15) at initializeProvider (/opt/wrapper.js:81:20) at processTicksAndRejections (internal/process/task_queues.js:95:5)

If anyone has any information about the stability of logs with this bug, please let us know. Thanks for your help.

These two are default propagators and currently live @opentelemetry/core. It is not clear what is part of core since it also has sampling implementations. It would be clear if they can be distributed along with api package or as a standalone package.

I remember in some other SIG seeing users complain that getContext() or context() can be confusing/distracting, and having a longer name could be a good thing.

For your consideration ;)

A few components have both their type + singleton exported, e.g. NOOP_TEXT_MAP_PROPAGATOR and NoopTextMapPropagator (likewise for NoopTracer, NoopTracerProvider, etc). Unless there's a technical reason to do this on purpose, I'd suggest exposing one or the another, in order to prevent confusion.

That typescript option only causes an issue if your import statement doesn't match the case of the file you're importing. It doesn't make different files have consistent casing.

I agree we should have guidance. I'll create an issue in the main repo to add it to the style guide

Originally posted by @dyladan in #147 (comment)

We should try to be more consistent in file naming and casing. Guidelines should be added to the style guide. All files don't need to be immediately updated, but all files in the future should follow the guide and we should make an effort to use switch to the new casing when doing refactorings.

Span#context was renamed in #45. For consistency, it would be nice if link did the same.

This is a minor ask – if we don't want to create more API churn this can be closed 🙂

Not a strong feeling on this, but you may consider moving diag/ to opentelemetry-js/core as it has actual implementation bits (similarly, other SIGs have additional packages/sections for such components). Not sure about any technical need for it at this level, so it's up to the maintainers to decide this ;)

The workflow test.yaml is referencing action actions/checkout using references v1. However this reference is missing the commit a6747255bd19d7a757dbdda8c654a9f84db19839 which may contain fix to the some vulnerability.
The vulnerability fix that is missing by actions version could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider to update the reference to the action.

As an optimization only Trace/Span Ids are being used for Link, instead of SpanContext. However, this means users have to deal with another type (that also is not in the specification).

Not a strong feeling though.

I stumbled upon an issue where it would be useful to additionally have a bind method which does not take a context argument, but a function returning a context. It's useful when binding event emitters as some of the emitted events might have different context active based on event types.

What do you think, would there be room for such a method?

Rough sketch (naming, parameter types of the callback uncertain)

public bind<T>(target: T, getContext: () => Context): T

More context here: open-telemetry/opentelemetry-js#2037

From the spec:

A Link is structurally defined by the following properties:

• SpanContext of the Span to link to.
• Zero or more Attributes further describing the link.

Seems pretty clear to me that the link should expose the whole SpanContext including the trace state.

Originally posted by @dyladan in #36 (comment)

Currently our Link is an object that shares some properties with SpanContext. Should we (1) add the missing properties to Link or should we (2) make it type Link = { spanContext: SpanContext, attributes: Attributes }?

To me, the spec seems to imply 2 is the more "correct" choice, but 1 is the less breaking change.

According to the documentation api.context.setGlobalContextManager() Returns the initialized context manager.

But actually it returns the ContextManager passed even if registerGlobal() detects that there is already a context manager installed and the passed ContextManager is not installed as global.

Similar api.propagation.setGlobalPropagator() returns the propagator passed instead that one installed global.

For api.trace.setGlobalTracerProvider() there is even a difference if installation happens as it always returns this._proxyTracerProvider.

I'm not sure what's correct here.

• Returning the current installed global version will cause problems in case of version mismatch
• Returning the passed in version may result in having two ContextManagers/TracerProviders/Propagators flying around

I think the best would be to return what one would get if they call api.trace.getTracerProvider() or api.context._getContextManager() (currently private) or api.propagation._getGlobalPropagator() (currently private). So either the global one (version matches) or Noop.