Why are bytes attributes encoded as strings?

[adriangb]

Does anyone know why the SDK encodes bytes attributes as strings?

https://github.com/open-telemetry/opentelemetry-python/blob/bede4d259aa497bd2d62d1dd249c0b43dc4067a2/opentelemetry-api/src/opentelemetry/attributes/__init__.py#L24C34-L25

There's no explanation given for this. This kneecaps the already poor ability of OTLP to represent data.

[adriangb]

cc @srikanthccv since you either implemented this or moved it from somewhere else based on eda57f7

[srikanthccv]

It wasn't the attribute length limit IIRC. The specification says

The attribute value is either:

• A primitive type: string, boolean, double precision floating point (IEEE 754-1985) or signed 64 bit integer.
• An array of primitive type values. The array MUST be homogeneous, i.e., it MUST NOT contain values of different types.

For this reason, All SDKs either don't support byte sequence or encode them as strings.

[adriangb]

I see. What was the purpose of allowing the transport to support bytes values then?

it’s truly a shame that opentelemetry didn't choose to be compatible with the most widely used serialization format: json. If it had chosen to support json + bytes or something like that we would have been able to re-use the vast ecosystem of “take my thing make it jsonable” (eg Pydantic in Python) to support serializing things in OTLP. It’s very close, IIRC map and Null are the only things missing. And bytes would be nice to have.

[srikanthccv]

There is experimental support according to this https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/attribute-type-mapping.md#byte-sequences. I don't see a reason to encode them as strings anymore. I think nobody complained and it remained unchanged.

[adriangb]

That's great news! Would a PR be accepted that removes this limitation then?

[srikanthccv]

Yes