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

Shutdown result is reported using boolean values #2406

Closed
ocelotl opened this issue Jan 24, 2022 · 6 comments · Fixed by #2599
Closed

Shutdown result is reported using boolean values #2406

ocelotl opened this issue Jan 24, 2022 · 6 comments · Fixed by #2599
Assignees
Labels
1.10.0rc1 release candidate 1 for metrics GA metrics

Comments

@ocelotl
Copy link
Contributor

ocelotl commented Jan 24, 2022

The spec says for both MeterProvider and MetricReader shutdown methods: Shutdown SHOULD provide a way to let the caller know whether it succeeded, failed or timed out.

Since there are 3 possible outcomes, the 2 possible boolean results are not enought and we need something else.

Originally posted by @ocelotl in #2405 (comment)

@ocelotl ocelotl self-assigned this Jan 24, 2022
@ocelotl ocelotl added 1.10.0rc1 release candidate 1 for metrics GA metrics labels Jan 24, 2022
@aabmass
Copy link
Member

aabmass commented Feb 1, 2022

What do we do in tracing?

@lzchen
Copy link
Contributor

lzchen commented Feb 1, 2022

Shutdown doesn't return anything in tracing.

@aabmass
Copy link
Member

aabmass commented Feb 1, 2022

What do you all think of raising exceptions for this? Having it not return anything and just raising an appropriate exception seems the most idiomatic to me.

@ocelotl
Copy link
Contributor Author

ocelotl commented Feb 1, 2022

What do you all think of raising exceptions for this? Having it not return anything and just raising an appropriate exception seems the most idiomatic to me.

I am ok with this, keep in mind that these exceptions need to be handled by some error handling mechanism.

@lzchen
Copy link
Contributor

lzchen commented Feb 1, 2022

@aabmass
What about logging an exception?

@owais
Copy link
Contributor

owais commented Feb 1, 2022

I think raising exception makes most sense here for Python. I don't think we can log an exception since we need to let the caller know which would be the calling scope code, not the human who wrote it.

Handling the exception ourselves will also defeat the purpose of having on in the first place as an exception here is meant to be used as a control flow mechanism.

I think we should look at these exceptions as more of control flow mechanism, document them and make them part of the public API for the packages. This way users and auto-instrumentation would be expected to always handle these two exceptions.

If we don't want exceptions then I guess the only way is to return an object which has fields to denote the result of the operation (or multiple values) but that doesn't feel very "pythonic".

ocelotl added a commit to ocelotl/opentelemetry-python that referenced this issue Apr 13, 2022
ocelotl added a commit to ocelotl/opentelemetry-python that referenced this issue Apr 13, 2022
ocelotl added a commit to ocelotl/opentelemetry-python that referenced this issue Apr 13, 2022
ocelotl added a commit that referenced this issue Apr 13, 2022
* Use exceptions to report shutdown result

Fixes #2406

* Fix mypy

* Make exceptions private

* Fix exceptions module path

* Remove exceptions and show failed metric readers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.10.0rc1 release candidate 1 for metrics GA metrics
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants