Can SeverityNumber go beyond 24?

[tisonkun]

What are you trying to achieve?

In the current spec, we define ranges of SeverityNumber:

SeverityNumber range	Range name	Meaning
1-4	TRACE	A fine-grained debugging event. Typically disabled in default configurations.
5-8	DEBUG	A debugging event.
9-12	INFO	An informational event. Indicates that an event happened.
13-16	WARN	A warning event. Not an error but is likely more important than an informational event.
17-20	ERROR	An error event. Something went wrong.
21-24	FATAL	A fatal error such as application or system crash.

And also reserve 0 as a possible unspecified value.

However, I wonder what happens if the passed severity number goes beyond 24?

What did you expect to see?

Need a clarification or answer.

Additional context.

Add any other context about the problem here. If you followed an existing documentation, please share the link to it.

This can be related to rust-lang/log#334 where people are evaluating opentelemetry's data model as its level repr.

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[tisonkun]

Related to #4540.

It's also undefined how to treat 0. I guess it's intented to leave it to implementor but that can cause some unnecessary unalignment.

[tisonkun]

Maybe resolved by #4478 (comment).

Then it's somehow different from what the relevant Go's libs impl:

• https://github.com/open-telemetry/opentelemetry-go/blob/log/v0.14.0/log/severity_string.go#L42
• https://cs.opensource.google/go/go/+/refs/tags/go1.25.3:src/log/slog/level.go;l=19-42

[pellared]

However, I wonder what happens if the passed severity number goes beyond 24?

Currently unspecified. Same applies for values below 0.

Then it's somehow different from what the relevant Go's libs impl:

I am not sure what you exactly mean. Can you be more precise? The fact someone can pass a severity below 0 or above 24 using Go Logs APi? In Go it is not possible to make an API that would disallow such calls. There are no enums like e.g. in Rust.

There was a discussion that it should could be defined as an enumeration in the specification, but most (all?) languages modeled it as an integer. Also changing integer -> enum is technically not backwards compatible (so e.g. OTel Java would stop being not specification compliant).

Having that said I think that representing SeverityNumber (why is it not named SeverityLevel... ) as enum in Rust may be a better option...

It's also undefined how to treat 0. I guess it's intented to leave it to implementor but that can cause some unnecessary unalignment

0 if allowed by the API should be treated as undefined. More: #4535