azure-sdk-for-js: [@azure/storage-blob] span.context is not a function

  • Package Name: @azure/storage-blob
  • Package Version: 12.6.0
  • Operating system:
  • nodejs
    • version: 14.15
  • browser
    • name/version:
  • typescript
    • version: 4.3.5
  • Is the bug related to documentation in

Describe the bug Context: Follow up to #13798

I understand this may not be related to @azure/storage-blob per se (as it look tracing related), but as the issue is triggered by a call to a code similar to the following one, I’ve figured this repo might be a good starting point.

  const bc = new BlobClient(cn, containerName, blobPath);
  const buf = await bc.downloadToBuffer();

Triggers an exception span.context is not a function

using the following dependencies:

  "dependencies": {
    "@azure/storage-blob": "^12.6.0",
    "@opentelemetry/api": "^1.0.1",
    "@opentelemetry/tracing": "^0.23.0",
    "applicationinsights": "^2.1.4"
  }

Which seems inline with https://github.com/open-telemetry/opentelemetry-js#compatibility-matrix

To Reproduce Steps to reproduce the behavior:

  1. Clone https://github.com/nulltoken/azure-storage-blob-repro-case
  2. edit repro.ts to value the connectionString, the containerName and the path to the blob
  3. yarn install
  4. yarn repro
$ yarn repro
yarn run v1.22.5
$ yarn node -r ts-node/register --unhandled-rejections=strict ./src/repro.ts
ApplicationInsights:An invalid instrumentation key was provided. There may be resulting telemetry loss [ '_your_ikey_' ]
## DEPENDENCY ######################################################
https://github.com/
########################################################
https://github.com/ 236784
## DEPENDENCY ######################################################
https://REDACTED.blob.core.windows.net/REDACTED/REDACTED?se=********************
########################################################
## EXCEPTION ######################################################
span.context is not a function
########################################################

C:\_work\repro\node_modules\@azure\core-http\src\policies\tracingPolicy.ts:79
      const spanContext = span.context();
                               ^
TypeError: span.context is not a function
    at TracingPolicy.<anonymous> (C:\_work\repro\node_modules\@azure\core-http\src\policies\tracingPolicy.ts:79:32)
    at step (C:\_work\repro\node_modules\tslib\tslib.js:143:27)
    at Object.next (C:\_work\repro\node_modules\tslib\tslib.js:124:57)
    at C:\_work\repro\node_modules\tslib\tslib.js:117:75
    at new Promise (<anonymous>)
    at Object.__awaiter (C:\_work\repro\node_modules\tslib\tslib.js:113:16)
    at TracingPolicy.sendRequest (C:\_work\repro\node_modules\@azure\core-http\dist\index.js:4430:22)     
    at StorageClientContext.ServiceClient.sendRequest (C:\_work\repro\node_modules\@azure\core-http\src\serviceClient.ts:303:25)
    at StorageClientContext.<anonymous> (C:\_work\repro\node_modules\@azure\core-http\src\serviceClient.ts:518:34)
    at step (C:\_work\repro\node_modules\tslib\tslib.js:143:27)
error Command failed.
Exit code: 1
Command: C:\Program Files\nodejs\node.exe
Arguments: -r ts-node/register --unhandled-rejections=strict ./src/repro.ts
Directory: C:\_work\repro
Output:

info Visit https://yarnpkg.com/en/docs/cli/node for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Expected behavior No exception 😉 ?

/cc @hectorhdzg

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 2
  • Comments: 19 (10 by maintainers)

Commits related to this issue

Most upvoted comments

Thanks for your patience everyone

At the time of this writing, @azure/core-tracing’s latest version is 1.0.0-preview13 and still references @opentelemetry/api v1.0.0-rc.0 which causes these problems.

Slight correction here: 1.0.0-preview12 and 1.0.0-preview13 of @azure/core-tracing use ^1.0.0 and ^1.0.1 of @opentelemetry/api respectively.

Talking about next steps…

Some of our packages already use 1.0.0-preview12 of @azure/core-tracing and so you should be free to use the latest @opentelemetry/api with them

  • All our core packages @azure/core-*
  • App Configuration
  • Event Hubs
  • Metrics Advisor
  • Service Bus
  • Tables
  • Text Analytics

The below packages will do the same in our August release

  • Form Recognizer
  • Key Vault
  • probably even the multiple packages for Communication Services

Since the storage packages are what is blocking the folks in this thread, we will ship an out of cycle release early next week where they are updated to use the newer @azure/core-tracing package and so can be usable with the latest @opentelemetry/api.

Apart from this, we will look into the compatibility matrix that @nulltoken was suggesting as well as documenting the best practices if you are using applicationinsights. That work is tracked in #15420 which you can subscribe to if you are interested.

That is a fair point @nulltoken We cannot expect users to look into the dependencies list in the package.json file to find the right version. This ought to have been documented. This becomes even more important now that @opentelemetry/api has gone GA i.e. has a stable release and has more people trying it out.

On the other hand, in our July release, we updated the @azure/core-tracing package to use ^1.0.0 of @opentelemetry/api. So, the packages that had an update then do use the latest @opentelemetry/api. But the catch is that there are still packages that took this change in their beta release or have not made a release yet.

Our August release will play catch up here, but may not cover all the packages. We can make a patch update for such packages to update the readme with a note on the supported version of @opentelemetry/api and @opentelemetry/tracing

@maorleger Thoughts?

@maorleger Indeed, it was a case of stale yarn.lock file. Fixed it with a yarn upgrade which bumped @azure/core-http to 2.1.0 and dropped all occurences of preview.12.

Thanks a lot for the tremendous support! ❤️

Just a thought, it’s a bit complicated to know which version of @azure/storage-blob, @opentelemetry/api, @opentelemetry/tracing, applicationinsights have been tested and proven compatible. Would there be a way to have a compatibility matrix so that updating dependencies becomes a little bit easier?

That is a fair point @nulltoken We cannot expect users to look into the dependencies list in the package.json file to find the right version. This ought to have been documented.

@ramya-rao-a Is there an issue I could subscribe to in order to track that topic?

I created https://github.com/Azure/azure-sdk-for-js/issues/16936 to address this documentation gap. Feel free to subscribe!

Quick update here: we believe we are all caught up, and haven’t heard otherwise. I worked with @hectorhdzg to ensure that applicationinsights@2.1.5 can both generate appInsights metrics and of course does not throw so I think we can close this issue.

Our upgrades going forward will be much smoother thanks to the investments we’re making now and since opentelemetry/api has gone GA. So I think we can close this.

but in my case I’ve got a mono repo using about 3-4 of the top level @azure/xxx SDK packages and I just cannot find a combination to align them

Can you share what those are?

Thanks @nulltoken!

This looks like a case of mismatched dependencies. @azure/storage-blob pulls in a preview version of @azure/core-tracing that depends on 1.0.0-rc.0 of @opentelemetry/api. While you are pulling in the version 1.0.1 of @opentelemetry/api

Can you update your dependency of @opentelemetry/api to 1.0.0-rc.0 and try again?

For a longer term fix, the next storage-blob update will be pulling in the latest of the @opentelemetry/api package.