[Bug]: Telemetry postinstall scripts crashing build servers

[KKings]

Package

@carbon/react

Browser

No response

Package version

1.54.0

React version

18.2.0

Description

When using Windows build agents and the npm package manager, running npm ci or npm i with only the @carbon/react package as a dependency causes multiple node processes to be created consuming all resources (CPU/Memory) and appear to be culprit for failings builds.

I cannot reproduce the issue on @carbon/react@1.38.0, only upgrading to the latest @carbon/react@1.54.0 causes the issue.

The environment variable, CARBON_TELEMETRY_DISABLED, is set at the machine level but does not appear to provide relief as the node processes are still queued.

Reproduction/example

N/A

Steps to reproduce

No link is provided, however, similar steps can be taken to reproduce:

1. Run npx create-next-app@latest and start a new Next.js project
2. Setup and configure @carbon/react@1.54.0
3. Use Carbon
4. Commit changes and run on a Windows build agent, our specs are 2 Core/16GB

For our usage, the carbon library is used to create a design system from the available components and so usage is throughout numerous React and @emotion/react components.

Suggested Severity

Severity 2 = User cannot complete task, and/or no workaround within the user experience of a given component.

Application/PAL

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct
• [X] I checked the current issues for duplicate problems

[francinelucca]

Hi! @KKings sorry telemetry is causing trouble with your builds. We have an open issue to mitigate this that you can track here https://github.com/ibm-telemetry/telemetry-js/issues/223. In the meantime, I would advise disabling telemetry collection, this should prevent all those processes from hogging resources. I see you tried disabling already using CARBON_TELEMETRY_DISABLED which is an old env var no longer in use, please use IBM_TELEMETRY_DISABLED='true'. For more info see Opting out of IBM Telemetry data collection

[jharvey10]

Hi @KKings! Would you mind letting me know a little more about the Windows build environment? Is it using WSL? Is it like a PowerShell terminal? Something else entirely?

My initial thought is that telemetry would have failed to run altogether in a Windows environment because we use some unix-style CLI commands for performance reasons to do things like listing dependencies or grabbing the set of tracked git files in the repo.

But it sounds like since you're hinting at resource exhaustion, it's at least getting far enough to run some of those commands, in which case this is definitely the known issue that @francinelucca mentioned.

I hope that after resolving the issue, we can gain your trust such that you'd be comfortable re-enabling telemetry, as that data really does help us make strategic decisions on what to support and where to enhance. But that's obviously your decision based on your comfort level.

[KKings]

@jdharvey-ibm Yes, it does appear to be related to resource exhaustion as each build failed at different parts and you can visually see the processes spinning up and fighting for resources.

The build environment itself is a Windows Virtual Machine with a Azure DevOps agent. The task runner is using PowerShell to run npm ci on a clean checkout.

[jharvey10]

Thanks, @KKings! That's super helpful. I certainly respect your decision to keep telemetry disabled if you so choose, but just to close the loop: We released @ibm/telemetry-js v1.5.0 today, which addresses the ram exhaustion issue. Carbon hasn't yet cut a release with this as the minimum required version in the semver range, but the next time you update the node modules in your project, you should expect to see telemetry v1.5.0 picked up.

[tay1orjones]

Yeah this should be closed in the next release, v11.57.0.

[tay1orjones]

v11.57.0 is out containing this fix