TypeError: coreTracing.createTracingClient is not a function

[StanislavHT]

• @azure/storage-blob:
• 12.23.0:
• Ubuntu22:
• [x] nodejs
  • 20.11.0:
• [x] typescript
  • 5.5.2:

Describe the bug When I run test case, it throws error. I downgraded version to 12.18.0, it works, but it doesn't work with 12.23.0

TypeError: coreTracing.createTracingClient is not a function

    4 |
    5 | import { DefaultAzureCredential } from '@azure/identity';
  > 6 | import {
      | ^
    7 |   BlobCopyFromURLResponse,
    8 |   BlobDeleteIfExistsResponse,
    9 |   BlobDeleteOptions,

    at Object.<anonymous> (node_modules/@azure/storage-blob/src/utils/tracing.ts:11:30)
    at Object.<anonymous> (src/azure/storage.ts:6:1)
    at Object.<anonymous> (src/azure/index.ts:1:1)
    at Object.<anonymous> (tests/azure/storage.test.ts:3:1)

[github-actions[bot]]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.

[xirzec]

Seems like an issue where the new version of @azure/storage-blob needs to bump its minimum dependency on @azure/core-tracing -- @StanislavHT can you tell me what version of core-tracing was being loaded when you got the failure?

[StanislavHT]

@xirzec

Now I'm using @azure/storage-blob 12.18.0, @azure/core-tracing 1.0.1 and it works. I'm not sure @azure/core-tracing version for @azure/storage-blob 12.23.0

[vritant24]

+1 to this, we faced the exact same issue with our server. reverting back to 12.18.0 fixed it for us as well

[KuSh]

Seems like an issue where the new version of @azure/storage-blob needs to bump its minimum dependency on @azure/core-tracing -- @StanislavHT can you tell me what version of core-tracing was being loaded when you got the failure?

Faced the same problem with 12.24.0. @azure/core-tracing was at version 1.1.2. Reverting to 12.18.0 switched back to @azure/core-tracing 1.0.0-preview.13

[kncvetko]

This issue is still active in 12.24.0 and updates of @azure/storage-blob to newer versions than 12.18.0 are not possible. Is there any roadmap to fix this? The urgency should be increased since without the fix updates of @azure/storage-blob are not possible and projects, which are running in highly regulated environments with the obligation to keep their 3rd party dependencies up to date will need to deal with compliance findings.

[studioab]

my workaround is to add "@azure/core-tracing": "^1.1.2" to deps

[EmmaZhu]

Hi All,

I cannot reproduce the issue. Maybe it only happens in some specific environment. Could anyone help to provide a little repro project?

[github-actions[bot]]

Hi @StanislavHT. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[maorleger]

Continuing the conversation from #31242 - @dhowell2000 (or other folks here) could you share more information or a small repro project that can be used to reproduce the issue?

You mentioned that things work fine locally, but not when pushing to Azure Web App. Do you have a lockfile that could be pulling an older version of core-tracing?

If you can, please run npm ls @azure/core-tracing in an environment that reproduces the issue and let us know the results.

Some more information that would help us:

• Are you using a test framework? Which one?
• Can you share your package.json with us?
• Is it only happening in a certain environment? Can you confirm the version of @azure/core-tracing in that environment (using the command I shared above)?

We'll continue investigating on our end

[dhowell2000]

It works fine on my development box (vscode on a mac)

When i push to my Azure Web App it breaks. I opened a Kudo console to the Web App and ran your requested command. This is what i got:

DEBUG CONSOLE | AZURE APP SERVICE ON LINUX

Documentation: http://aka.ms/webapp-linux Kudu Version : 20240822.2 Commit : a86ad9d31002b0e2111a20f21ebaeae4be986b94

kudu_ssh_user@a84d3d69020e:/$ npm ls @azure/core-tracing / └── (empty)

kudu_ssh_user@a84d3d69020e:/$

Here is the dependency part of my package.json "dependencies": { "@azure/communication-email": "^1.0.0", "@azure/communication-sms": "^1.1.0", "@azure/core-tracing": "^1.1.2", "@azure/identity": "^4.4.1", "@azure/keyvault-keys": "^4.8.0", "@azure/keyvault-secrets": "^4.8.0", "@azure/monitor-opentelemetry": "^1.7.1", "@azure/storage-blob": "^12.25.0", "@ffmpeg-installer/ffmpeg": "^1.1.0", "apn": "^2.2.0", "applicationinsights": "^3.3.0", "chalk": "^4.1.2", "dayjs": "^1.11.11", "dotenv": "^16.3.1", "express": "^4.18.2", "ffmpeg-static": "^5.2.0", "fluent-ffmpeg": "^2.1.3", "json5": "^2.2.3", "jsonwebtoken": "^9.0.2", "mongodb": "^6.8.0", "mongoose": "^8.0.3", "ms": "^2.1.3", "multer": "^1.4.5-lts.1", "sharp": "^0.33.4", "swagger-jsdoc": "^6.2.8", "swagger-ui-express": "^5.0.1", "uuid": "^10.0.0", "ws": "^8.18.0" }, "devDependencies": { "chai": "^5.1.1", "jest": "^29.7.0", "mocha": "^10.7.3", "supertest": "^7.0.0", "swagger-autogen": "^2.23.7" }, "pkg": { "scripts": [ "bin/www", "api/v1/v1ApiDiscoveryRouter.js" ], "assets": [ "public//", "views//", "config/**/", "bin//", "node_modules/sharp//*", "node_modules/open/xdg-open" ], "targets": [ "node16-macos-x64" ] } }

[dhowell2000]

it works in Azure if i go back to this:

"@azure/storage-blob": "12.18.0",

[dhowell2000]

it appears i was in the wrong directory when i ran the bash command that returned the empty result. If needed i can redeploy the broken state tomorrow and run it.

The value i get when it is WORKING using 12.18.0 is:

kudu_ssh_user@a84d3d69020e:~/site/wwwroot$ npm ls @azure/storage-blob npm notice npm notice New major version of npm available! 9.6.7 -> 10.8.3 npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.8.3 npm notice Run npm install -g [email protected] to update! npm notice [email protected] /home/site/wwwroot └── @azure/[email protected]

kudu_ssh_user@a84d3d69020e:~/site/wwwroot$ npm ls @azure/core-tracing [email protected] /home/site/wwwroot ├─┬ @azure/[email protected] │ ├─┬ @azure/[email protected] │ │ └── @azure/[email protected] deduped │ ├─┬ @azure/[email protected] │ │ └── @azure/[email protected] deduped │ └─┬ @azure/[email protected] │ └── @azure/[email protected] deduped ├─┬ @azure/[email protected] │ └── @azure/[email protected] deduped ├── @azure/[email protected] ├─┬ @azure/[email protected] │ └── @azure/[email protected] deduped ├─┬ @azure/[email protected] │ └── @azure/[email protected] deduped ├─┬ @azure/[email protected] │ └── @azure/[email protected] deduped ├─┬ @azure/[email protected] │ └─┬ @azure/[email protected] │ └── @azure/[email protected] deduped ├─┬ @azure/[email protected] │ ├─┬ @azure/[email protected] │ │ └── @azure/[email protected] │ └── @azure/[email protected] └─┬ [email protected] └─┬ @azure/[email protected] └── @azure/[email protected] deduped

since it isn't listed as a dependency in the working case (so maybe not needed by 12.18), i am wondering if you took a dependency post 12.18 and forgot to somehow register it.

[maorleger]

it appears i was in the wrong directory when i ran the bash command that returned the empty result. If needed i can redeploy the broken state tomorrow and run it.

Yes, that would be great - let us know what outputs then.

since it isn't listed as a dependency in the working case (so maybe not needed by 12.18), i am wondering if you took a dependency post 12.18 and forgot to somehow register it.

It's possible but right now I don't think likely. I'll give some context here that might help.

• @azure/[email protected] depends on @azure/[email protected]
• @azure/[email protected] depends on @azure/core-tracing@^1.0.0
• createTracingClient was added to @azure/core-tracing as part of GA version (1.0.0)
  • Technically I believe it was added in preview.14 but for all intents and purposes we can focus on preview.13 vs 1.0.0

When I see coreTracing.createTracingClient is not a function, my first hunch is that @azure/storage-blob is still finding preview.13 of core-tracing which does not have createTracingClient.

Theoretically this should all work seamlessly when you update your dependencies - when you update a dependency and run npm update <name> (or npm install after updating package.json, npm (or yarn or pnpm)) npm should resolve correctly and make any updates necessary to transitive dependencies.

I've seen cases where partial updates or other dependency resolution changes are not fully applied, and the new version of a package continues "finding" the older version of its dependency.

Some things that have helped in the past

• Deleting node_modules and package-lock.json , then running npm install is the most likely way to fix the dependency resolution issues; however, this is not always possible or feasible.
• Running npm ls @azure/core-tracing (or yarn why or pnpm list depending on your package manager) should list out all transitive and direct dependencies on @azure/core-tracing. This could help find older versions of core-tracing still hanging around
• All else fails, I do believe the workaround listed here should help https://github.com/Azure/azure-sdk-for-js/issues/30147#issuecomment-2327198020

Hope this helps a bit, and possibly offers some debugging / workaround tips, but of course we want to help so feel free to reach out with any information that may help us repro this!

[dhowell2000]

Thanks for the info.

This is ONLY happening when I push to an Azure Web App. Not when I build and run locally. (BTW explicitly adding core tracing to the dependencies didn't work for me.)

So if your theory of an older preview "hanging around" is correct, it is only happening in Azure (for me). I could see that might happen if Azure "upgrades" vs "clean installs" since my web app has been around for a while. I'm not sure how Azure handles the update pushes. I use a GitHub action to push and deploy in Azure.

How do I clean out Azure properly to force the preview to be cleared? And as a second question isn't this an Azure bug/issue?

[maorleger]

Thanks for the info.

This is ONLY happening when I push to an Azure Web App. Not when I build and run locally. (BTW explicitly adding core tracing to the dependencies didn't work for me.)

Right, I know this. It would be great to know what npm ls @azure/core-tracing from the project directory returns when its in a bad state.

So if your theory of an older preview "hanging around" is correct, it is only happening in Azure (for me). I could see that might happen if Azure "upgrades" vs "clean installs" since my web app has been around for a while. I'm not sure how Azure handles the update pushes. I use a GitHub action to push and deploy in Azure.

How do I clean out Azure properly to force the preview to be cleared?

As a test you could deploy to a new environment

And as a second question isn't this an Azure bug/issue?

It may be, and we would love to get it sorted out, but it's relatively rare and we've been unable to reproduce the issue. Any repro steps would be very helpful! @azure/core-tracing gets roughly 7 million downloads per week. @azure/storage-blob gets roughly 2 million downloads per week with ~50% of those being 12.23 and higher. By comparison, reports of this issue have been very rare.

To be clear, we don't want to see anyone struggle here - with a minimal repro we'd love to get to the bottom of it and help y'all. Some workarounds have been posted but ideally would not be needed if we can get a stable repro of the issue

[github-actions[bot]]

Hi @StanislavHT, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

[github-actions[bot]]

Hi @StanislavHT, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!