Updating @azure/storage-blob from v12.5.0 to 12.6.0 is causing exceptions and breaking functionality

[subuv]

• @azure/storage-blob:
• ^12.6.0:
• Windows 10 Pro:
• nodejs
  • 14.15.1:
• browser
  • name/version:
• typescript
  • version:
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://docs.microsoft.com

Describe the bug
Updating storage-blob to v12.6.0 from v12.5.0 is implicitly updating "core-tracing" to "1.0.0-preview.11". It is also removing reference to package "opentelemetry/api" thereby breaking already existing functionality. This is not a minor update as how the documentation claims it to be.

To Reproduce
Steps to reproduce the behavior:

1. Update npm package @azure/storage-blob to v12.6.0

Expected behavior
This update should not be a breaking change as it is claimed to be a minor update.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Exception Stacktrace:
TypeError: _a.context is not a function\n at Object.getSpanContext (C:\Developer\Proje
ct\DataCatalog\node_modules\@opentelemetry\api\build\src\context\context.js:70:76)\n at getParent (C:\Developer\Project\DataCatalog\node_modules\@opentelemetry\tracing\build\src\
Tracer.js:101:16)\n

[maorleger]

Hi @subuv, thank you so much for creating this issue.

First, I am sorry for the disruption this must have caused you - I can imagine that it can be very frustrating!

1. I'd love to get a bit more information about your specific configuration - could you share the dependencies and depDependencies sections of your package.json file? Not everything is important, but what I am interested in is any dependency that is @azure/<package-name> besides storage-blob of course, as well as any dependency that is @opentelemetry/<package> . Their corresponding versions would be important here as well.
2. I see that the error is coming from @opentelemetry itself - to confirm: are you using distributed tracing in your application?
3. If you have a minimal repro that you can point me to, that would really help here. If not, I can work backwards from the information you provide in (1) and (2)

Looking forward to hearing from you!

Maor

[subuv]

1. Attaching a snip of it here.
   
2. We do not. It is coming from a dependency package of @azure/storage-blob.
3. Apologies I cannot a repo here.

[EmmaZhu]

Hi @subuv

Is this issue blocking your scenario now? Do you have a workaround for it?

We'll try to have a repro in our local environment. Will update you with any progress.

Thanks
Emma

[maorleger]

Seems related to #13798 although that issue references @azure/[email protected]

I tried reproducing this by starting with @azure/storage-blob 12.5.0 and upgrading to @azure/storage-blob 12.6.0 and running the same bit of code that lists blobs (see below) and did not run into this error.

@EmmaZhu - have you been able to reproduce this yet?

@subuv I'm really sorry for the disruption this has caused. Unforutnately @opentelemetry/api has been in beta for quite some time, which meant that our tracing support has been in beta as well. Now that @opentelemetry/api has stabilized at 1.0 we expect this to stabilize as well; however, we do not expect to break customers that are not using tracing and if we did - I'd like to get it fixed and resolved. But I am unable to reproduce this by following the flow I described above so I need some more information:

can you share a complete stack trace if you can reproduce this?
Also, what happens if you delete node_modules and package-lock.json and run npm install again - does it reproduce?
Finally, if you ran npm ls @opentelemetry/api - can you share the output?

Here's my code snippet that worked across storage blob upgrades:

import { BlobServiceClient } from "@azure/storage-blob";
import { DefaultAzureCredential } from "@azure/identity";

async function main() {
  const client = new BlobServiceClient(
    "https://my_storage.blob.core.windows.net",
    new DefaultAzureCredential()
  );
  const containerClient = client.getContainerClient("test");
  for await (const blob of containerClient.listBlobsFlat()) {
    console.log(blob.name);
  }
}

main()
  .then(() => console.log("done"))
  .catch((err) => console.log(err));

[subuv]

Hi Emma/Maor,

Thank you for getting back on this. As of now it is not a blocker for us. I have the stacktrace from when i reported this, providing it here. But if openTelemetry/api update to a stabilized 1.0 is not causing this, i will try updating @azure/storage-blob again and see if i am able to reproduce this.

Stacktrace:
TypeError: _a.context is not a function
at Object.getSpanContext (/usr/app/node_modules/@opentelemetry/api/build/src/context/context.js:70:76)
at getParent (/usr/app/node_modules/@opentelemetry/tracing/build/src/Tracer.js:101:16)
at Tracer.startSpan (/usr/app/node_modules/@opentelemetry/tracing/build/src/Tracer.js:49:31)
at Tracer.tracer.startSpan (/usr/app/node_modules/diagnostic-channel-publishers/dist/src/azure-coretracing.pub.js:55:44)
at /usr/app/node_modules/@azure/core-tracing/dist/index.js:727:27
at BlockBlobClient. (/usr/app/node_modules/@azure/storage-blob/dist/index.js:20060:30)
at step (/usr/app/node_modules/tslib/tslib.js:143:27)
at Object.next (/usr/app/node_modules/tslib/tslib.js:124:57)
at /usr/app/node_modules/tslib/tslib.js:117:75
at new Promise ()
at Object.__awaiter (/usr/app/node_modules/tslib/tslib.js:113:16)
at BlockBlobClient.BlobClient.download (/usr/app/node_modules/@azure/storage-blob/dist/index.js:20051:22)
at download (/usr/app/src/azureBlob/blobStoreClient.js:31:59)
at tryBlobAction (/usr/app/src/azureBlob/keyResilientBlobStoreClient.js:60:18)
at retrieveBlob (/usr/app/src/azureBlob/keyResilientBlobStoreClient.js:19:18)
at getCurrentVersions (/usr/app/src/catalog/entityVersion/entityVersionManager.js:60:48)
at catalogLookupRequestAdapter (/usr/app/src/controllers/catalogLookupController.js:84:65)
at Layer.handle [as handle_request] (/usr/app/node_modules/express/lib/router/layer.js:95:5)
at next (/usr/app/node_modules/express/lib/router/route.js:137:13)
at requestValidatorMiddleware (/usr/app/node_modules/express-openapi/dist/index.js:93:25)
at Layer.handle [as handle_request] (/usr/app/node_modules/express/lib/router/layer.js:95:5)
at next (/usr/app/node_modules/express/lib/router/route.js:137:13)

npm ls @opentelemetry/api:

[maorleger]

@hectorhdzg FYI - is this the same issue as #13798 and if so, would it be resolved by updating applicationinsights to 2.1.4? Certainly seems like a dupe but I wanted to confirm

[hectorhdzg]

@maorleger yes updating to applicationinsigths to 2.1.4 must solve this issue

[maorleger]

Thanks for confirming! @subuv could you try applicationinsights 2.1.4 and see if it resolves your issue? If so, feel free to close this issue.

[subuv]

Updating to applicationinsights 2.1.4 has solved this issue. Thank you @hectorhdzg, @maorleger and @EmmaZhu!

[murphyliam]

We seem to be facing the same issue reported above when attempting to use azure storage but:

a) none of the fixes seem to address the problem
b) this is impacting a production system

Our packages are currently: "dependencies": {
"@azure/storage-blob": "^12.7.0",
"@opentelemetry/api": "1.0.2",
"@opentelemetry/tracing": "^0.24.0",
"acorn": "^6.0.0",
"applicationinsights": "^2.1.5",

The code where the context issue is being triggered is:

try {
const blobServiceClient = BlobServiceClient.fromConnectionString(xxxx);
const containerClient = blobServiceClient.getContainerClient(containerName);
const createContainerResponse = await containerClient.createIfNotExists();
if (createContainerResponse) {
return containerClient;
} else {
throw new Error(
Failed to connect to storage with connection string (${xxx}).
);
}
} catch (err) {
throw new Error(
Storage Connection Error (${err.message}, connection string: ${xxx}).
);
};

As you can imagine this is pretty urgent for us so any assistance would be appreciated.....

[maorleger]

Hey @murphyliam - I can try to help but I am unfortunately unable to reproduce this with the packages listed above.

What I tried:

set the following package.json dependencies:

    "@azure/storage-blob": "^12.7.0",
    "@opentelemetry/api": "1.0.2",
    "@opentelemetry/tracing": "^0.24.0",
    "acorn": "^6.0.0",
    "applicationinsights": "^2.1.5"

run npm install

When I check for @opentelemetry/api I see they are all on the same compatible version:

validation main % npm ls @opentelemetry/api
[email protected] /home/mleger/workspace/azure-sdk-experiments/validation
├─┬ @azure/[email protected]
│ └─┬ @azure/[email protected]
│   └── @opentelemetry/[email protected]  deduped
├── @opentelemetry/[email protected] 
└─┬ [email protected]
  └── @opentelemetry/[email protected]  deduped

Same with core-tracing:

validation main % npm ls @azure/core-tracing
[email protected] /home/mleger/workspace/azure-sdk-experiments/validation
└─┬ @azure/[email protected]
  ├─┬ @azure/[email protected]
  │ └── @azure/[email protected]  deduped
  ├─┬ @azure/[email protected]
  │ └── @azure/[email protected]  deduped
  └── @azure/[email protected] 

Finally, I run the code snippet you shared and all works as expected

I have a few questions for you:

• Is this happening consistently or just in one environment?
• Can you reproduce this locally?
• If you can reproduce this locally (or can get on a machine where this error shows up), what is the output of npm ls @azure/core-tracing and npm ls @opentelemetry/api ?
• Finally, if you can reproduce this locally, does deleting the package-lock.json file and the node_modules directory and then running npm install help with that at all?

Thanks!

[murphyliam]

Thanks for the quick response; I've duplicated this post in 16947 as realised this post has been flagged as closed....to answer you initial questions:

• we have 2 azure environments where this has started happening, first noticed last week
• local dev machines (both Windows 10 and OS\X) the problem does not occur

[murphyliam]

..to clarify the above, the local dev machines both point to the same azure hosted storage containers. Its only when we host the nodejs project on azure directly where we start getting the exceptions; that is an ubuntu image hosted in an azure app service.