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
neha-bhargava
left a comment
There was a problem hiding this comment.
I did a quick test with MISE exporter too and logs look fine. Thanks!
…mpatibility (#5720) * Initial plan * Fix fallback where OpenTelemetry instrumentation is not available Follow up to #4487 --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: James May <fowl2@users.noreply.github.com> Co-authored-by: Neha Bhargava <61847233+neha-bhargava@users.noreply.github.com>
Fixes #4456. An alternative to #4486 solution.
Changes proposed in this request
Testing