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
doc(api): clearify TextMapPropagator API requirements
The current interface places the generic paramter on the interface
itself. This implies that the implementors of `TextMapPropagator`
can specify what carrier types it accepts (and that each implementor
only work with one specific type of carrier).
```ts
interface TextMapPropagator<Carrier> {
inject(context: Context, carrier: Carrier, setter: TextMapSetter<Carrier>): void;
extract(context: Context, carrier: Carrier, getter: TextMapGetter<Carrier>): void;
}
```
In reality, this is not the case.
The propagator API is designed to be called by participating code
around the various transport layers (such as the `fetch` inst on
the browser, or integration with the HTTP server library on the
backend), and it is these callers that ultimately controls what
carrier type the currently configured propagator is called with.
Therefore, a correct implementation of this interface must treat
the carrier as an opaque value, and only work with it using the
provided getter/setter.
Ideally, the interface should look like this instead:
```ts
interface TextMapPropagator {
inject<Carrier>(context: Context, carrier: Carrier, setter: TextMapSetter<Carrier>): void;
extract<Carrier>(context: Context, carrier: Carrier, getter: TextMapGetter<Carrier>): void;
}
```
This communicates and enforces the contract. Unfortunately, that
would be a breking change we are not currently prepared to make.
Instead, this commit updates the documentation to explicitly
document the discrapancy and advice implemntors the correct way
forward.
It also updates our own implementations to follow the recommended
pattern, as well as updating the tests to be more well-behaved
around this, as some of them are written to rely on this exact
behavior that would be problematic in the real world.
Ref open-telemetry#5365
Ref open-telemetry#5368
0 commit comments