Move to opentelemetry 0.31.

[marc-pydantic]

(currently opening this to get a CI run)

The underlying opentelemetry should at some point migrate from 0.30 to 0.31, if only to because some transitive dependencies have moved on, e.g. prost.

The tracing-opentelemetry crate had some unforced changes going from 0.30 to 0.31 (opentelemetry version, NOT tracing-opentelemetry, which confusingly is a one minor version ahead).

This branch is using a fork of tracing-opentelemetry that has manually seen its opentelemetry updated.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[cetra3]

Would it be easier if you move this in as a module to this crate?

[marc-pydantic]

I'd say equally different. I assume this is a stopgap measure for now.

[cetra3]

This may not work with the greater ecosystem as well, which sucks. There are some other crates we are using that depend on tracing-opentelemetry like axum-tracing-opentelemetry and reqwest-tracing

[davidhewitt]

Can we just update to tracing-opentelemetry 0.32?

[marc-pydantic]

Can we just update to tracing-opentelemetry 0.32?

Not straight away, as the underlying API has changed significantly in the meantime, for reasons I don't understand yet. After spending a few fruitless hours trying to replicate the old logfire behavior with the new API, I made a fork of the unaltered version of tracing-opentelemetry and simply put in opentelemetry 0.31 instead. It "just worked", showing there was no need to do a breaking change before said version bump.

The breaking change occurred here: tokio-rs/tracing-opentelemetry#202 -- you'll see that others have also felt the changes. There's already some work in undoing some of the damage (tokio-rs/tracing-opentelemetry#234), it might be that eventually a more backwards-compatible version of tracing-opentelemetry comes out again, which we could then use.