No way to "unset" span limits

[owais]

https://github.com/open-telemetry/opentelemetry-specification/blob/03a6f0fd9d1d2f5e08858b102ba620ebf3e4a6fa/specification/trace/sdk.md#span-limits

Spec does not specify how to unset these limits. Python SDK does not support a way to do this either. Setting them to 0 actually sets the limit to 0. Not integer values are not supported. I'll work with Python SIG to add a way to remove these limits. For now I'm gonna set this defaults to a large enough number such as 999999. Any objections or comments?

//cc @flands @MrAlias @pellared

[pellared]

1. I would use the defaults 128 as defined by the spec.
2. I understand it like that: "if an SDK implements the limits then it should NOT ALLOW unbounded collections (unlimited mode not possible)". This is what I would personally do. It may be good to make a PR to clarify it.
3. Another possibility is that a negative value could mean that the collection is unbounded. Personally, I would not like it, because it increases the implementation complexity to support both mechanisms and we lose some "safety" e.g. in case of a memory overflow caused by recursive instrumentation.

I can make a PR in OTel specs if you all agree.

[iNikem]

Ask client facing persons :) E.g. @flands. That was his command back in the days of splunk-otel-java birth.

[mateuszrzeszutek]

FYI:

Distribution MUST default to 1000 for OTEL_SPAN_LINK_COUNT_LIMIT (not OpenTelemetry default)

If I remember correctly, that was the default setting in splunk-otel-java because the Java SDK was trying to eagerly allocate an array or a list with that size. That may be not true for other languages.
Maybe we should relax the requirement to "unlimited or a reasonably large number" for all SpanLimits setttings?

[owais]

Maybe we should relax the requirement to "unlimited or a reasonably large number" for all SpanLimits setttings?

This sounds most reasonable to me to unblock things right away. I'm just not sure what a "reasonably large number" would be and was hoping to get an answer/suggestions from this discussion. Let's see if PST/EST people have a strong opinion :)

[mateuszrzeszutek]

I'm just not sure what a "reasonably large number" would be

🤷‍♂️
Depends on the language? I can imagine that setting 9999999999999999999 would be perfectly okay if you don't pre-allocate anything (and have no way of setting "unlimited"). And setting 1000 (let's say, order of magnitude bigger than OTel) would be the correct choice when the collection is eagerly allocated.

[owais]

I don't think any optimizations like pre-allocation should affect the limits we support. Limit is a user facing concept strictly dictating upper limits of the data we collector. Each language can pre-allocate based on what the most common size is.

I'm going to go ahead with a arbitrarily large number for Python until I fix this in the SDK. This will be an internal details so I'll not document it anywhere and instead document it as "unlimited" or "unset".

[owais]

I think setting any large number that makes it the same as unset in practice temporarily while support is added to the Otel project is the way to go. Otel Python will support it soon and Splunk's distro will be updated accordingly. I don't think GDI spec needs to account for in-development state so this discussion can be closed.