`parseKeyPairsIntoRecord()` filters out pairs with an empty value, and perhaps should not

[trentm]

I think the behaviour of function parseKeyPairsIntoRecord excluding entries were the value is an empty string may be a longstanding bug. The Baggage spec (https://www.w3.org/TR/baggage/#definition) defines the value to be:

value                  =  *baggage-octet

which, IIUC, allows the value to be empty.

Originally posted by @trentm in #5885 (comment)

---

parseKeyPairsIntoRecord() from the @opentelemetry/core module is a utility from the baggage support, originally for parsing strings in the baggage header, as defined by https://www.w3.org/TR/baggage

> core.parseKeyPairsIntoRecord('foo=bar,nada=')
{ foo: 'bar' }

[trentm]

Some history:

• 2021-05 feat(exporter-collector): support config from env #2099 #2117 factored out baggage parsing to the re-usable parseKeyPairsIntoRecord() function, and changed the behaviour (intentional or not) to filter out key/value pairs with an empty pair. The intended re-use is for header parsing of OTEL_EXPORTER_OTLP_TRACES_HEADERS and similar.
• 2025-04 refactor(opentelemetry-core): simplify parseKeyPairsIntoRecord() #5610 simplifies the impl of parseKeyPairsIntoRecord() and adds a test case that an empty value should be skipped.

A use case to be aware of is that parsing of various *_HEADERS by packages in the OTel JS SDK use this function. So the change in behaviour means that OTEL_EXPORTER_OTLP_TRACES_HEADERS=foo=bar,nada= would now result in a nada HTTP header being included. (Personally I think that would be fine. HTTP allows headers with empty values.)

---

Actually I think we should consider a further change (perhaps for a separate issue/PR) the separate the utilities for parsing baggage and for parsing *_HEADERS envvars, because baggage allows metadata after each key-pair:

> core.parseKeyPairsIntoRecord('foo=bar;this-is-my-metadata,spam=eggs')
{ foo: 'bar', spam: 'eggs' }

[trentm]

FWIW, I believe the "let's use Baggage-parsing logic for the headers envvars" stems from this in the spec:

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md#specifying-headers-via-environment-variables says (emphasis mine):

The OTEL_EXPORTER_OTLP_HEADERS, OTEL_EXPORTER_OTLP_TRACES_HEADERS, OTEL_EXPORTER_OTLP_METRICS_HEADERS, OTEL_EXPORTER_OTLP_LOGS_HEADERS environment variables will contain a list of key value pairs, and these are expected to be represented in a format matching to the W3C Baggage, except that additional semi-colon delimited metadata is not supported, i.e.: key1=value1,key2=value2. All attribute values MUST be considered strings.

Issues I see with the OTel JS implementation:

• It is accepting the baggage semi-colon delimited metadata (which is surprising to me).
• The baggage spec has limitations on which US-ASCII chars can be used for the value which don't apply to HTTP headers in general. A significant one is probably intentional: baggage values may not use whitespace, but a common envvar usage uses a space OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer my-token".

[pichlermarc]

Actually I think we should consider a further change (perhaps for a separate issue/PR) the separate the utilities for parsing baggage and for parsing *_HEADERS envvars, because baggage allows metadata after each key-pair:

Yes, absolutely. I just re-used it in the config code as that was what we already had used before. We can then also remove the export for parseKeyPairsIntoRecord() in 3.0 since it's not used anywhere else outside of the @opentelemetry/core package.