Opentelemetry-specification: How to discard over limited data on span

[XSAM]

specification/trace/sdk.md says in Span Limits section:

To protect against such errors, SDK Spans MAY discard attributes, links, and events that would increase the number of elements of each collection beyond the configured limit.

I feel like it is not very clear that how we should discard this data. Should we discard the oldest data that added in the first place or the new data that we want to append?

This behavior that how to discard data should be consistent with all the SDK, which will influence spans' final result.

[bogdandrutu]

@XSAM very good call, I was discussing this with few others and decision was to not rush and define that before we put some effort into documented pros cons for every possibility. For the moment I have seen both options new data are dropped when already limit reached and FIFO. I think we need somebody to start thinking about this and document pros and cons for both, definitely I would be against a "random drop" approach :)

[arminru]

I interpret the definition above as "any excess items are dropped while leaving the current items in place". This is also the intended handling as far as I remember but we could indeed point that out a bit more clearly.

We always had some kind of "streaming" SDK in mind that would dispatch attributes right when being set. In this case, overwriting the oldest attributes in a ring buffer fashion would not be possible. Even though I haven't seen such a streaming implementation yet, it could make sense to send span data available at start right away (i.e., the data provided to the span builder) and the rest on span end, which would lead to the same limitation.

I can see reasons for preserving the last couple of attributes (e.g., the HTTP status code) but the attributes required for "identifying" the traced operation are usually set at the very beginning of a span, so I think the current definition is the better trade-off given that and the alternative SDK implementations above. Ideally we would probably say we preserve, for example, the first 80% and the last 20%, but that would not be easily to implement. Anyway we're not talking about "normal use cases" here but rather error handling when attributes/events/links are added (accidentally) in a loop, for example, so we should go for an inexpensive handling method like making any further add calls a no-op.

[MrAlias]

the attributes required for "identifying" the traced operation are usually set at the very beginning of a span,

I think this is a really good point :+1: