search

Azure / azure-sdk-for-js

This repository is for active development of the Azure SDK for JavaScript (NodeJS & Browser). For consumers of the SDK we recommend visiting our public developer docs at https://docs.microsoft.com/javascript/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-js.
MIT License
2.06k stars 1.19k forks source link

TypeError: coreTracing.createTracingClient is not a function #30147

Open StanislavHT opened 3 months ago

StanislavHT commented 3 months ago

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] commented 3 months ago

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

xirzec commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

+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 commented 2 months ago

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 commented 1 month ago

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 commented 4 weeks ago

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

EmmaZhu commented 1 week ago

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] commented 1 week ago

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 commented 6 days ago

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:

We'll continue investigating on our end

dhowell2000 commented 5 days ago

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 commented 5 days ago

it works in Azure if i go back to this:

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

dhowell2000 commented 5 days ago

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 npm@10.8.3 to update! npm notice memboxservice@1.0.0 /home/site/wwwroot └── @azure/storage-blob@12.18.0

kudu_ssh_user@a84d3d69020e:~/site/wwwroot$ npm ls @azure/core-tracing memboxservice@1.0.0 /home/site/wwwroot ├─┬ @azure/communication-email@1.0.0 │ ├─┬ @azure/communication-common@2.3.1 │ │ └── @azure/core-tracing@1.1.2 deduped │ ├─┬ @azure/core-client@1.9.2 │ │ └── @azure/core-tracing@1.1.2 deduped │ └─┬ @azure/core-rest-pipeline@1.17.0 │ └── @azure/core-tracing@1.1.2 deduped ├─┬ @azure/communication-sms@1.1.0 │ └── @azure/core-tracing@1.1.2 deduped ├── @azure/core-tracing@1.1.2 ├─┬ @azure/identity@4.4.1 │ └── @azure/core-tracing@1.1.2 deduped ├─┬ @azure/keyvault-keys@4.8.0 │ └── @azure/core-tracing@1.1.2 deduped ├─┬ @azure/keyvault-secrets@4.8.0 │ └── @azure/core-tracing@1.1.2 deduped ├─┬ @azure/monitor-opentelemetry@1.7.1 │ └─┬ @azure/opentelemetry-instrumentation-azure-sdk@1.0.0-beta.6 │ └── @azure/core-tracing@1.1.2 deduped ├─┬ @azure/storage-blob@12.18.0 │ ├─┬ @azure/core-http@3.0.4 │ │ └── @azure/core-tracing@1.0.0-preview.13 │ └── @azure/core-tracing@1.0.0-preview.13 └─┬ applicationinsights@3.3.0 └─┬ @azure/core-rest-pipeline@1.16.3 └── @azure/core-tracing@1.1.2 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 commented 5 days ago

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.

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

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 commented 4 days ago

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 commented 8 hours ago

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