Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verify compliant metric SDK specification implementation: Numerical limits handling #3670

Closed
2 tasks done
Tracked by #3674
MrAlias opened this issue Feb 3, 2023 · 6 comments
Closed
2 tasks done
Tracked by #3674
Assignees
Labels
area:metrics Part of OpenTelemetry Metrics pkg:SDK Related to an SDK package

Comments

@MrAlias
Copy link
Contributor

MrAlias commented Feb 3, 2023

  • Identify all the normative requirements, recommendations, and options the specification defines as comments to this issue
  • Ensure the current metric SDK implementation is compliant with these normative requirements, recommendations, and options in those comments.
@MrAlias MrAlias converted this from a draft issue Feb 3, 2023
@MrAlias MrAlias added pkg:SDK Related to an SDK package area:metrics Part of OpenTelemetry Metrics labels Feb 3, 2023
@pellared pellared moved this from Todo to In Progress in Go: Metric SDK (GA) Jun 6, 2023
@pellared pellared self-assigned this Jun 6, 2023
@pellared
Copy link
Member

pellared commented Jun 7, 2023

The SDK MUST handle numerical limits in a graceful way according to Error handling in OpenTelemetry.

From: https://github.com/open-telemetry/opentelemetry-specification/blob/v1.21.0/specification/error-handling.md#basic-error-handling-principles

OpenTelemetry implementations MUST NOT throw unhandled exceptions at run time.

The [...] SDK SHOULD provide safe defaults for missing or invalid arguments.

Whenever the library suppresses an error that would otherwise have been exposed to the user, the library SHOULD log the error using language-specific conventions.

The specification only calls out aggregation_cardinality_limit which is not implemented (it is experimental).

@pellared
Copy link
Member

pellared commented Jun 7, 2023

If the SDK receives float/double values from Instruments, it MUST handle all the possible values. For example, if the language runtime supports IEEE 754, the SDK needs to handle NaNs and Infinites.

Exploratory tested with NaN, Inf+, Inf-. Results: #4209. Everything works as expected.

@pellared
Copy link
Member

pellared commented Jun 7, 2023

It is unspecified how the SDK should handle the input limits. The SDK authors MAY leverage/follow the language runtime behavior for better performance, rather than perform a check on each value coming from the API.

This is explicitly not normative.

@pellared
Copy link
Member

pellared commented Jun 7, 2023

It is unspecified how the SDK should handle the output limits (e.g. integer overflow). The SDK authors MAY rely on the language runtime behavior as long as errors/exceptions are taken care of.

This is not normative. However, there is a requirement that "OpenTelemetry implementations MUST NOT throw unhandled exceptions at run time." that needs to be checked.

Integer overflows are not causing runtime panic at runtime. The value is simply overflown. Reference: https://go.dev/ref/spec#Integer_overflow

@pellared
Copy link
Member

pellared commented Jun 7, 2023

It looks like we comply with this fragment of the specification.

@MrAlias Can you please double-check and close if you agree with my verification?

@MrAlias
Copy link
Contributor Author

MrAlias commented Jun 7, 2023

LGTM

@MrAlias MrAlias closed this as completed Jun 7, 2023
@github-project-automation github-project-automation bot moved this from In Progress to Done in Go: Metric SDK (GA) Jun 7, 2023
@MrAlias MrAlias added this to the v1.17.0/v0.40.0 milestone Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:metrics Part of OpenTelemetry Metrics pkg:SDK Related to an SDK package
Projects
No open projects
Development

No branches or pull requests

2 participants