Skip to content

Conversation

maurocchi
Copy link
Contributor

@maurocchi maurocchi commented Sep 11, 2024

https://prima-assicurazioni-spa.myjetbrains.com/youtrack/issue/PAPAY-1395

After upgrading this library in our application, we observed the following errors logged after every execution of a scheduled tasks:

A Tokio 1.x context was found, but it is being shutdown.
thread '<unnamed>' panicked at .cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.40.0/src/runtime/time/entry.rs:568:9:

This is related to open-telemetry/opentelemetry-rust#1961.

It appears that we should explicitely shutdown the tracer provider, otherwise it doesn't flush all the data when the application terminates. Additionally, the process remains active and the Tokio' runtime complains.

@maurocchi maurocchi changed the title [PAPAY-1395]: Tokio error on shutdown [PAPAY-1395]: Explicitely shutdown the tracer provider Sep 11, 2024
@maurocchi maurocchi force-pushed the PAPAY-1395/task/tokio-error-on-shutdown branch from 94760c1 to d8e950c Compare September 11, 2024 13:32
@maurocchi maurocchi marked this pull request as ready for review September 11, 2024 13:34
@maurocchi maurocchi requested a review from a team as a code owner September 11, 2024 13:34

let mut tracer_provider = TRACER_PROVIDER
.lock()
.expect("OpenTelemetry tracer provider mutex poisoned");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about gracefully handle the poison error recovering the old state?

Copy link
Contributor Author

@maurocchi maurocchi Sep 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be poisoned if another thread panicked while it has the mutex locked. But this lock is used only 2 times, at startup and at shutdown.

At startup should not be possible to have a poisoned lock, because noone kept the lock before. At shutdown, it can be poisoned only if the startup panicked (precisely, if mem::replace(&mut *tracer_provider, Some(new_provider)) panicked). But in this case shutdown_tracer_provider will not be called.

So, this seems a good case to use expect, like done by opentelemetry::global::set_tracer_provider...


let tracer_provider = TRACER_PROVIDER
.lock()
.expect("OpenTelemetry tracer provider mutex poisoned")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

cottinisimone
cottinisimone previously approved these changes Sep 12, 2024
@cottinisimone cottinisimone merged commit 50d9dfd into master Sep 12, 2024
7 checks passed
@cottinisimone cottinisimone deleted the PAPAY-1395/task/tokio-error-on-shutdown branch September 12, 2024 07:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants