-
Notifications
You must be signed in to change notification settings - Fork 347
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
Downgrade System.Diagnostics.DiagnosticSource to v6 and add a check if OpenTelemetry instrumentation can be used #4487
Conversation
thanks for referencing this issue, so even downgrading still causes some issues? |
Currently downgrading doesn't cause issues. However, it's not future-proof if we ever need newer APIs. Additionally, if the client app enables exporters, OpenTelemetry libraries 1.4.0 and above depend on DiagnosticSource 7.0.0+, so they'll have to use one of the workarounds anyway. |
Have you thought about merging both PRs? So that it fixes the assembly load and fallbacks when Az Functions moves from 6 to 8 (?). Alternatively, this PR is enough and when Az Functions updates, the upgrade will break some folks. This should be a strong signal that they need to figure out a better solution. Thoughts? |
Were you able to test this with the exporter manually? |
Yea, I'll merge the PRs. You mean when Azure Functions update their runtime to v8? I tested with a v5 library and everything works. So if they upgrade to v9 and we use v6/7, it's okay.
Yes, with the dev app. Workarounds still needed for in-process Function, but works otherwise. |
* Adds a check if OTel can be used. * Comments. More specific error type.
Pull request was converted to draft
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a quick test with MISE exporter too and logs look fine. Thanks!
Fixes #4456. An alternative to #4486 solution.
Changes proposed in this request
Testing