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

POTEL 26 - Customize OpenTelemetry Scope.close behaviour #3517

Merged

Conversation

adinauer
Copy link
Member

@adinauer adinauer commented Jun 25, 2024

#skip-changelog

📜 Description

Replace the default ThreadLocalContextStorage with SentryOtelThreadLocalStorage which hands back a different Scope implementation that on .close() does not check whether the current active Context is the one it expects.

💡 Motivation and Context

By default ScopeImpl.close() in OpenTelemetry checks whether the current active Context is the one from back when Context was forked. This means if during lifecycle of this Scope anything does not clean up properly, we're stuck with an outdated Context that holds a Span reference. This Span has already ended but will be used as parent for other requests coming in and breaks tracing for follow up requests.

With the customized behaviour in this PR, we're now ignoring whether an inner Scope was not closed properly and clean up anyways.

The problem with improper cleanup is not an easy one to fix. Sentry static API makes use of getCurrentScopes() which, forks scopes and sets it on the IScopesStorage if there's no valid Scopes for the current Thread available. This creates a lifecycle token that is ignored, since we don't know where to actually restore the previous Context.

We tested this using server.tomcat.threads.max=1 in application.properties so there is only one thread handling requests. Before this change, the second request would fail to properly create transactions/spans and does not send anything to Sentry.

More details:
OTel changed this behaviour to support things like Camel, where Scope.close() might be called multiple times. See open-telemetry/opentelemetry-java#5055

Risks:
This could mean when close calls go out of order, we end up with a different state than before. However this scenario probably means random result anyways.

💚 How did you test it?

📝 Checklist

  • I reviewed the submitted code.
  • I added tests to verify the changes.
  • No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
  • I updated the docs if needed.
  • Review from the native team if needed.
  • No breaking change or entry added to the changelog.
  • No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

Copy link
Contributor

github-actions bot commented Jun 25, 2024

Messages
📖 Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 202d89f

Copy link
Collaborator

@lbloder lbloder left a comment

Choose a reason for hiding this comment

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

Left a question about license, otherwise LGTM 👍

@lbloder lbloder mentioned this pull request Jun 25, 2024
7 tasks
Base automatically changed from feat/potel-25-workaround-for-agent-non-auto-init to 8.x.x June 25, 2024 14:15
@adinauer adinauer merged commit d924cd1 into 8.x.x Jun 26, 2024
3 of 21 checks passed
@adinauer adinauer deleted the feat/potel-26-customize-otel-thread-local-storage-behaviour branch June 26, 2024 05:19
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