[bugfix/tracing] fix broken tracing due to conflicting schema url

[milas]

Description

The OpenTelemetry SDK is very strict about the schema version when the Resource is initialized.

Specifically, different schema versions CANNOT be mixed, and since the default SDK resource (which is merged with the user-defined one) defines a schema URL, the semconv imports are really prone to being out-of-sync.

The best way to avoid this is to merge a schemaless resource. This is fine...there's plenty of other ways to get semconv out of sync, and the core service attributes (e.g. service.name) should not ever change.

Additionally, any errors here are now propagated so that they'll be visible instead of silently swallowed.

Checklist

• I/we have read the GoToSocial contribution guidelines.
• I/we have discussed the proposed changes already, either in an issue on the repository, or in the Matrix chat.
• I/we have not leveraged AI to create the proposed changes.
• I/we have performed a self-review of added code.
• I/we have written code that is legible and maintainable by others.
• I/we have commented the added code, particularly in hard-to-understand areas.
• I/we have made any necessary changes to documentation.
• I/we have added tests that cover new code.
• I/we have run tests and they pass locally with the changes.
• I/we have run go fmt ./... and golangci-lint run.

[tsmethurst]

Ah thanks for this :)

So this won't cause a regression to the issue described here #2503 ?

[daenney]

Ah yeah, that seems better. Then we should be able to update the otel dependencies too going forwards without problems.

[milas]

So this won't cause a regression to the issue described here #2503 ?

Nope! Using schemaless should insulate us from it breaking again.

Longer explanation follows with more than you want to know because the semconv situation is...weird, and I've broken & fixed it across several Docker¹ repos now 🙈

---

semconv are well-known/standardized fields, and while there have been breaking changes, the service.name key is pretty fundamental and changing it would break EVERYTHING OTel-related, so I don't think it's a risk.

Another possibility is to add a test for constructing the Resource, which would catch the breakage when updating go.mod in CI, but that's a bit of a nuisance since it means looking at the OTel SDK source to find what semconv version it uses.

Footnotes

1. disclaimer: I work at Docker Inc but my contributions to GoToSocial are my own work and not sponsored or endorsed by them. ↩