fix(deps): bump uuid from 8.3.2 to 11.1.1 across the packages that declare it

[bsod90]

uuid@^8.3.2 is affected by GHSA-w5hq-g745-h8pq (moderate) — "Missing buffer bounds check in v3/v5/v6 when buf is provided" — first patched in 11.1.1.

Ten packages now land on ^11.1.1: the nine that declared ^8.3.2 (api-gateway, backend-native, backend-shared, clickhouse-driver, cubestore-driver, databricks-jdbc-driver, playground, schema-compiler, server-core) plus client-core, which was on ^11.1.0.

Why ^11.1.1 and not the newest 14.x

It is the lowest version that clears the advisory, and it lets every declared range collapse onto one resolution instead of introducing a second modern major.

Bumping client-core from ^11.1.0 turned out to be required, not cosmetic: yarn v1 keeps a pre-existing resolution rather than re-resolving it upward, so leaving it alone left client-core and the transitive @cubejs-backend/jdbc on 11.1.0 — before the fix, and exactly the version this PR exists to remove. Verified from the lockfile:

uuid@^11.1.0, uuid@^11.1.1:  version "11.1.1"
uuid 11.x versions resolved: ['11.1.1']  -> single copy: True

The 8 → 11 jump is API-neutral here

Every call site uses named imports, all still exported by v11:

import	packages
v4	server-core, api-gateway (×3), schema-compiler, cubestore-driver, clickhouse-driver, playground, client-core, backend-native test
v1 + v5	backend-shared process.ts
parse	server-core CompilerApi.ts

Nothing imports the default export, which is what v7 removed — the usual breakage on this upgrade. v11 ships dual CJS/ESM with a require condition, so the CommonJS consumers resolve dist/cjs/index.js; no interop change.

@types/uuid removed

Six packages declared @types/uuid@^8.3.x (api-gateway, schema-compiler, server-core, playground, databricks-jdbc-driver, and query-orchestrator — which doesn't even declare uuid). uuid v11 bundles its own types and the DefinitelyTyped stub is deprecated for v7+.

This wasn't breaking a build, since TS resolves the bundled dist/cjs/index.d.ts ahead of @types/. But it left a v8-shaped stub that could take over under a typeRoots/paths setup, or outlive the runtime dependency. It is now absent from both the lockfile and node_modules.

Verification

Runtime shapes checked against 11.1.1 directly:

uuid version: 11.1.1
named exports present: v1=function v4=function v5=function parse=function
v5(v1(), v1()): 5dff62e3-5b30-5472-9b07-b4bf9a1dc373 | valid shape: true
parse(v4()) byte length: 16 (expect 16)
v4 stable across calls (distinct): true

Types check without the stub — v4(), v5(v1(), v1()) and parse() all compile under strict with types: [] against uuid's own declarations.

cubejs-backend-shared typechecks clean and its 392 tests pass; processUid (the one non-v4 consumer) generates correctly from built output. api-gateway shows no uuid-related type errors.

What this does not do

uuid 8/9/10 remain in the lockfile via third parties — aws-sdk (8.0.0), sockjs, snowflake-sdk, @google-cloud/storage, @azure/msal-node, @cypress/request (^8.x), @google-cloud/bigquery, gaxios (^9.x), dockerode (^10.x). Those are outside what this repo declares and would need upstream bumps or a resolutions entry — a separate decision. The alert is raised against the declared dependency, which this clears.

🤖 Generated with Claude Code

[claude]

Claude finished @bsod90's task in 2m 53s —— View job

---

Review: mostly sound, but the dedupe claim doesn't hold — 1 medium, 2 low

The 8 → 11 upgrade is API-safe for every call site in this repo. But the lockfile still resolves uuid@11.1.0 for cubejs-client-core, which is pre-patch for the very advisory this PR clears, so the alert won't fully go away. Two inline comments posted.

Full review — findings, verification, and todo list

Todo

• Gather context (diff, package.json changes, lockfile)
• Verify every uuid call site is API-compatible with v11
• Check for missed declarations / @types/uuid leftovers
• Check module-format (ESM/CJS) and Node engine implications
• Post review

Findings

1. Medium — the lockfile didn't dedupe; uuid@11.1.0 survives (inline, yarn.lock:24102)

The description states the tree "ends up with a single 11.1.1". It doesn't:

uuid@^11.1.0:   version "11.1.0"    <- cubejs-client-core, @cubejs-backend/jdbc@0.9.0
uuid@^11.1.1:   version "11.1.1"    <- the nine packages bumped here

Yarn v1 left the existing ^11.1.0 resolution alone instead of floating it up. 11.1.0 is before the GHSA-w5hq-g745-h8pq fix, so a version-based scanner keeps flagging it. Real exploitability is nil — cubejs-client-core imports only v4, and the bug is the buf bounds check in v3/v5/v6 — but the alert is the thing this PR is trying to clear. Bumping client-core to ^11.1.1 and dropping the stale lock entry collapses both ranges (@cubejs-backend/jdbc's ^11.1.0 follows along, since 11.1.1 satisfies it).

2. Low — stale @types/uuid@^8.x in six packages (inline, cubejs-api-gateway/package.json:52)

api-gateway, schema-compiler, server-core, playground, databricks-jdbc-driver, and query-orchestrator all still pull @types/uuid@8.3.4. uuid v11 bundles its own types and the DT stub is deprecated for v7+. Not breaking today (the package's own types wins module resolution), but it's dead weight pinned to the old major.

3. Low — v4({ random }) isn't in the verification list, and nothing pins its output

CompilerApi.mixInVisibilityMaskHash (packages/cubejs-server-core/src/core/CompilerApi.ts:1068-1071) is the one non-trivial use — uuidv4({ random: sha256(...).subarray(0, 16) }), deriving a deterministic compiler id from a hash. The PR's verification covers bare v4(), v5(v1(), v1()), and parse(), but not this options form.

It is safe: v11 still accepts V4Options.random, applies the same rnds[6] = (rnds[6] & 0x0f) | 0x40 / rnds[8] = (rnds[8] & 0x3f) | 0x80 bit-setting as v8, and skips the native.randomUUID fast path whenever options is passed — so the same 16 bytes produce the same UUID string. The Buffer passed as random is fine, Buffer extends Uint8Array. Worth calling out because output stability here feeds cache/compiler identity: a silent change would shift keys, not throw. A one-line assertion (v4({random: <fixed 16 bytes>}) === '<expected>') would make that guarantee explicit rather than inferred.

4. Nit — unrelated lockfile churn

The diff also merges string-width-cjs/strip-ansi-cjs/wrap-ansi-cjs alias entries into their base specs. Benign yarn re-serialization, no version movement, just noise in a security-fix diff.

What checked out

Check	Result
Import shapes	All 9 runtime call sites use named imports (v4, v1+v5, parse) — nothing touches the default export v7 removed
Node engines	Every bumped package declares node >= 20; uuid v11 needs ≥ 16
CJS interop	v11's exports.require → dist/cjs/index.js; all consumers here are CJS-compiled TS
Playground bundling	Vite + >0.2% and supports es6-module browserslist — resolves exports conditions natively, no ES5-downlevel concern
parse() return	Uint8Array in both v8 and v11; Buffer.from() wrapper unaffected
processUid	v5(v1(), v1()) — v1() is a valid namespace string in v11
Version choice	^11.1.1 over 14.x is the right call: lowest version clearing the advisory, minimal blast radius

cubejs-databricks-jdbc-driver declares uuid but has no import of it in src/ — pre-existing, out of scope, but it could be dropped rather than bumped.

· branch [`maxim/uuid-8-to-11`](https://github.com/cube-js/cube/tree/maxim/uuid-8-to-11)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.59%. Comparing base (b1c87dc) to head (880d860).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #11534      +/-   ##
==========================================
- Coverage   84.03%   79.59%   -4.45%     
==========================================
  Files         257      480     +223     
  Lines       81220    99544   +18324     
  Branches        0     3636    +3636     
==========================================
+ Hits        68253    79229   +10976     
- Misses      12967    19796    +6829     
- Partials        0      519     +519     

Flag	Coverage Δ
cube-backend	59.28% <ø> (?)
cubesql	84.06% <ø> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[claude]

Claude finished @bsod90's task in 1m 16s —— View job

---

Re-review of 880d860: both prior findings fixed — 0 blocking, 1 nit

The dedupe now actually holds in the lockfile, and @types/uuid is gone from the tree entirely. Nothing new blocking; both of my earlier threads are already resolved.

Full review — verification, remaining nit, todo list

Todo

• Verify the dedupe actually landed in yarn.lock
• Verify @types/uuid removal is complete
• Re-check call sites / missed declarations
• Check prior threads, post review

Finding 1 (medium) — fixed

yarn.lock:24092 now collapses both ranges onto one entry:

uuid@^11.1.0, uuid@^11.1.1:
  version "11.1.1"

11.1.0 is gone from the lockfile; the only 11.x present is 11.1.1. packages/cubejs-client-core/package.json:43 is ^11.1.1, and @cubejs-backend/jdbc's ^11.1.0 rides along on the shared entry. That was the one thing standing between this PR and the advisory alert actually clearing for the declared deps.

Finding 2 (low) — fixed

"@types/uuid" no longer appears in any packages/*/package.json, and the @types/uuid@8.3.4 lock entry is deleted outright (no other consumer was holding it). The removal covers all six, including cubejs-query-orchestrator, which never declared uuid at all.

Finding 3 (low) — acknowledged in the commit message, not asserted in code

CompilerApi.mixInVisibilityMaskHash (packages/cubejs-server-core/src/core/CompilerApi.ts:1068) uses v4({ random: <sha256 bytes> }) to derive a deterministic compiler id. It is safe on v11 — V4Options.random is still honored, the same version/variant bit-setting applies, and the native.randomUUID fast path is skipped whenever options are passed, so identical bytes give an identical string. Still no test pinning that output, which is the one place where a silent change would shift cache/compiler identity rather than throw. Optional; not worth blocking a security bump on.

I couldn't execute node/yarn in this run (no node_modules in the checkout, and the runtime probe was denied), so this pass is lockfile- and source-level verification rather than a re-run of the author's runtime checks.

Nit (pre-existing, out of scope)

packages/cubejs-databricks-jdbc-driver declares uuid but has no import of it in src/ — could be dropped rather than bumped, but that's unrelated to the advisory.

State after both commits

Check	Result
Declared uuid ranges	10 packages, all ^11.1.1
Lockfile 11.x entries	one — 11.1.1
@types/uuid	absent from all package.json files and from the lockfile
Call sites	13 imports, all named (v4, v1+v5, parse) — none touch the default export v7 removed
Residual old uuid	8.0.0 / ^8.x / ^9.x / ^10.x remain via third parties only (aws-sdk, sockjs, snowflake-sdk, @cypress/request, dockerode, …) — as the description says, a separate decision

· branch [`maxim/uuid-8-to-11`](https://github.com/cube-js/cube/tree/maxim/uuid-8-to-11)