[x-telemetry] Skip runtime resolution when telemetry is disabled

[aemartos]

• I have followed (at least) the PR section of the contributing guide.

Fixes #22070

Summary

• Check shouldSendTelemetry before calling getTelemetryContext() in sender.ts, so disabled telemetry doesn't trigger fetch('/package.json')
• Add tests verifying no fetch is made when telemetry is disabled (via settings or CI)

Context

When telemetry was disabled via muiXTelemetrySettings.disableTelemetry(), env var, or CI environment, a fetch('/package.json') request was still being made on every telemetry event. This caused issues in test environments that monitor unhandled requests.

The root cause: sender.ts called getTelemetryContext() (which resolves runtimePackageNameHash via fetch('/package.json')) before checking whether telemetry should be sent.

Fix

Reorder the checks in sendMuiXTelemetryEvent:

1. Load the base context (no runtime resolution, no fetch)
2. Check shouldSendTelemetry with the base context, early exit if disabled
3. Only then call getTelemetryContext() to resolve runtime values

The base context already has everything shouldSendTelemetry needs (isCI is set at postinstall time), so no additional work is required for the eligibility check.

[code-infra-dashboard]

Bundle size

Bundle	Parsed size	Gzip size
@mui/x-data-grid	0B(0.00%)	0B(0.00%)
@mui/x-data-grid-pro	0B(0.00%)	0B(0.00%)
@mui/x-data-grid-premium	0B(0.00%)	0B(0.00%)
@mui/x-charts	0B(0.00%)	0B(0.00%)
@mui/x-charts-pro	0B(0.00%)	0B(0.00%)
@mui/x-charts-premium	0B(0.00%)	0B(0.00%)
@mui/x-date-pickers	0B(0.00%)	0B(0.00%)
@mui/x-date-pickers-pro	0B(0.00%)	0B(0.00%)
@mui/x-tree-view	0B(0.00%)	0B(0.00%)
@mui/x-tree-view-pro	0B(0.00%)	0B(0.00%)

Details of bundle changes

Deploy preview

https://deploy-preview-22078--material-ui-x.netlify.app/

---

Check out the code infra dashboard for more information about this PR.

[LukasTy]

LGTM. 👌
The 2nd and 3rd Claude observations could be worth checking.

Claude Opus 4.6 review

Summary

The fix is correct and well-motivated. The core change in sender.ts reorders the logic so the eligibility check happens before the expensive getTelemetryContext() call (which triggers fetch('/package.json')).

Correctness Analysis

The key question is: does shouldSendTelemetry() work correctly with the base context (before runtime resolution)?

Looking at what shouldSendTelemetry actually checks:

1. typeof window === 'undefined' — no context needed
2. getTelemetryEnvConfigValue('IS_COLLECTING') — no context needed (this is where disableTelemetry() sets the flag via settings.ts)
3. telemetryContext.traits.isCI — set at postinstall time by ci-info, never modified by getTelemetryContext()

And getTelemetryContext() only adds: sessionId, anonymousId, runtimePackageNameHash, projectId, fingerprint — none of which are used by shouldSendTelemetry.

Additionally, since telemetryContext from ../context is a singleton (the same object getTelemetryContext() mutates and returns), baseTelemetryContext and the resolved context are literally the same reference. So the check is guaranteed to produce the same result either way.

Things that look good

• The payload still uses the fully resolved context (with runtimePackageNameHash, fingerprint, etc.) — only the eligibility check was moved earlier
• The new beforeEach resets for runtimePackageNameHash and runtimePackageNameHashResolved prevent test pollution from the new tests that set these to null/false
• Both disabling paths are tested (programmatic disableTelemetry() and CI environment)

Minor observations (non-blocking)

1. Dynamic vs static import — The new await import('../context') follows the existing pattern of dynamic imports in sendMuiXTelemetryEvent. However, ../context is an extremely lightweight module (just a plain object, no side effects), and other lightweight modules like getTelemetryEnvConfigValue and fetchWithRetry are already imported statically at the top of the file. A static import telemetryContext from '../context' would be simpler and avoid the async overhead on every call. Not critical since it's consistent with the get-context import pattern, but worth considering.

2. Type import inconsistency — TelemetryContextType is still imported from './get-context' (line 1), while the value is now imported from '../context'. Both resolve to the same type (since get-context re-exports it from ../context), so no bug, but importing both from '../context' would be cleaner.

3. Pre-existing test cleanup gap — The existing test "should not send telemetry when opted out via settings" (line 89) calls disableTelemetry() but never cleans up. It only works because the next test happens to call enableTelemetry(). The PR's new test correctly calls enableTelemetry() at the end, which is good. Worth noting afterEach doesn't reset the telemetry settings — fragile test ordering is a pre-existing issue, not introduced here.

Verdict

Approve — the fix is correct, the tests cover the important cases, and the change is minimal and focused. The minor observations above are non-blocking style preferences.

[aemartos]

@LukasTy suggestions addressed!