feat(mysql-aurora-serverless-driver): Migrate from aws-sdk v2 to @aws-sdk/client-rds-data

[ovr]

aws-sdk v2 reached end-of-support on 2025-09-08, so GHSA-rvhx-wmgm-m6q9 will never get a patched release — this swaps the driver over to @aws-sdk/client-rds-data ^3.1048.0 and bumps data-api-client to ^2.4.1, which takes the v3 client as an optional peer instead of bundling the v2 SDK. The driver never used aws-sdk at runtime (it talks to Aurora through data-api-client), so the only code changes are the type import in driver/index.d.ts (ClientConfiguration -> RDSDataClientConfig) and the integration test, which now passes region / credentials / endpoint through the driver's options instead of setting AWS.config.* globals. @types/data-api-client floats 1.2.3 -> 1.2.11, which swapped its aws-sdk dependency for @types/aws-sdk2-types, so aws-sdk leaves the lockfile entirely and 2 Dependabot alerts close.

Verified against the real local-data-api + MySQL 5.6.50 compose stack: the driver's integration suite passes 3/3 and unit 2/2, plus yarn tsc and a no-op yarn install --frozen-lockfile.

Check List

• Tests have been run in packages where changes have been made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

🤖 Generated with Claude Code

[claude]

Claude finished @ovr's task in 3m 26s —— View job

---

Review complete — approve with nits: 0 high, 1 medium, 2 low (3 inline comments)

Full review

• Read PR diff
• Read driver source + package.json + both test files + README
• Check remaining aws-sdk consumers and lockfile resolution
• Handle prior review threads
• Post findings

Verdict

The migration itself is right: the driver never touches the SDK directly (only data-api-client at driver/AuroraServerlessMySqlDriver.js:13), aws-sdk is gone from the lockfile in the runtime tree, and @aws-sdk/client-rds-data is correctly a direct dependencies entry since driver/index.d.ts:1 now imports a type from it. The author's run against the real local-data-api + MySQL 5.6.50 stack is the relevant evidence that options still reaches the client under data-api-client@2.

Findings

#	Sev	Where	Concern
1	medium	test/AuroraServerlessMySqlDriver.integration.js:36	v2-shaped options (accessKeyId/secretAccessKey, sslEnabled, httpOptions, maxRetries) are silently dropped by RDSDataClientConfig; breaking for users, but the commit is a plain feat: with no migration note
2	low	package.json:31	@types/data-api-client left at ^1.2.1 (v1 types) against runtime 2.4.1; still pulls @types/aws-sdk2-types, so v2 SDK typings remain in the lockfile
3	low	package.json:23	^3.1048.0 floor duplicates the whole AWS SDK v3 core stack (@aws-sdk/core 3.974 + 3.978, @smithy/core 3.23 + 3.33, two credential-provider-node subtrees) instead of deduping with the athena/redshift/s3 drivers

No security or performance concerns in the changed code; no comment-hygiene findings (the diff removes a stale commented-out AWS.config.credentials line, which is an improvement).

Not verified

yarn install / yarn tsc and the integration suite were not run here — no node_modules in the checkout and no npm-registry access from this sandbox, so data-api-client@2's peer declaration and config-key handling were read from the lockfile and the diff rather than executed. The author reports 3/3 integration, 2/2 unit, yarn tsc, and a clean --frozen-lockfile.

Review threads

The listing returned 0 of my own threads (empty first page, hasNextPage: false) — no prior threads, so none resolved and none re-affirmed. All 3 findings posted as new inline comments.

• branch `cherry-pick-135a6d3-as-feat`

[claude]

This hunk is the evidence that the swap is breaking for users, not type-only. options is passed straight through to the client in driver/AuroraServerlessMySqlDriver.js:65, so an existing config like

{ options: { accessKeyId: '…', secretAccessKey: '…', sslEnabled: false, maxRetries: 5 } }

used to authenticate under RDSDataService; under RDSDataClient those keys are not part of RDSDataClientConfig and are silently dropped — credentials fall back to the default provider chain and the query fails with a credentials/auth error at runtime rather than a config error at startup. httpOptions/maxRetries likewise become no-ops (requestHandler/maxAttempts now).

The test had to be rewritten for exactly this reason, so the same rewrite is required of every user who sets options. Worth a BREAKING CHANGE: footer on the commit (the PR is currently a plain feat:) plus a one-line migration note — v2 accessKeyId/secretAccessKey → credentials: { … }, sslEnabled dropped, maxRetries → maxAttempts. The driver is community-supported with no docs page, so the changelog entry is the only place a user will see it.

[ovr]

@claude I am ok with such minor breaking change, I hope it doesn't affect anyone.

[claude]

Claude finished @ovr's task in 30s —— View job

---

Acknowledged — finding 1 closed as won't-fix

• Read trigger comment and current branch state
• Re-check the two remaining nits against HEAD

Your call on the breaking change, and the blast radius is genuinely small: the only affected users are ones who set options.accessKeyId/secretAccessKey/sslEnabled/httpOptions/maxRetries on this driver specifically. Anyone relying on the default provider chain (IAM role, env vars, ~/.aws/credentials) is unaffected, since RDSDataClient picks those up the same way v2 did. Treating it as a plain feat: is fine with me — dropping it here so the reasoning is on the record.

The other two findings are independent of the breaking-change question and still stand on HEAD:

#	Where	Nit
2	package.json:31	@types/data-api-client still ^1.2.1 against runtime 2.4.1; keeps @types/aws-sdk2-types (v2 typings) in the lockfile
3	package.json:23	^3.1048.0 floor forks a second AWS SDK v3 core tree instead of deduping with the athena/redshift/s3 drivers

Both are cosmetic for correctness — the driver is plain JS, so #2 types nothing at runtime, and #3 only costs lockfile lines and image size. Happy to push either or both if you want them in this PR:

• Bump the types →
• Lower the SDK floor →

Otherwise this LGTM as-is — no code changes pushed in this run.
• branch cherry-pick-135a6d3-as-feat

[claude]

The break is a bit wider than sslEnabled. AWS SDK v2's ClientConfiguration also accepted credentials and transport settings at the top level — accessKeyId, secretAccessKey, sessionToken, maxRetries, httpOptions — and options is passed straight through to new RDSDataClient(...) (driver/AuroraServerlessMySqlDriver.js:64). v3 ignores unknown constructor keys, so a JS cube.js doing

options: { accessKeyId: '...', secretAccessKey: '...', region: 'us-east-1' }

no longer errors on config — it silently falls back to the default credential chain and fails later with CredentialsProviderError: Could not load credentials from any providers, which does not point at the config key that moved. TS users get a compile error from the RDSDataClientConfig swap; JS users get nothing.

Two ways to keep it painless, either is fine:

• a changelog/release note listing the moved keys (accessKeyId/secretAccessKey/sessionToken → credentials, maxRetries → maxAttempts, sslEnabled → drop and use an https endpoint);
• or map the v2 shape in the constructor when options.accessKeyId is present, so existing configs keep working.

No docs page covers this driver's options, so the note is the only place a user would find out.

[claude]

Reviewing PR #11904

• Read PR diff and driver source
• Verify data-api-client v2 API/peer-dep compatibility
• Check remaining aws-sdk references across repo
• Check lockfile / version alignment
• Resolve stale review threads, post findings

View job run

[claude]

Claude finished @ovr's task in 3m 19s —— View job

---

Review — looks good; 0 new inline comments (1 pre-existing thread still open, answered in place)

Full review

• Read the PR diff
• Read the driver source (runtime usage of data-api-client)
• Check the v2 → v3 client-config surface
• Verify lockfile / dependency resolution
• Handle prior review threads
• Post findings

Verdict

The migration is sound. The driver never touches aws-sdk at runtime — options is handed to data-api-client, which constructs the client (driver/AuroraServerlessMySqlDriver.js:64) — so the ClientConfiguration → RDSDataClientConfig swap in driver/index.d.ts:8 plus the dependency change is genuinely the whole of it.

Checks that came back clean:

• aws-sdk v2 has no entries left in yarn.lock, and neither do @types/data-api-client / @types/aws-sdk2-types.
• @aws-sdk/client-rds-data": "^3.1048.0" resolves to 3.1130.0 with a single merged @aws-sdk/core (3.978.0), @smithy/core and @aws-sdk/credential-provider-node subtree — no duplicate SDK trees against the ^3.22.0/^3.726.0 floors in the athena/redshift/snowflake/base drivers.
• @aws-sdk/client-rds-data sits in dependencies, not devDependencies, which is what driver/index.d.ts needs for consumer type resolution and what data-api-client v2 needs for its optional peer.
• mysql-aurora-serverless is in the integration matrix (.github/workflows/push.yml:425), so the local-data-api compose run gates this in CI rather than only locally.
• No docs page mentions this driver (grep -ril aurora docs-mintlify → nothing), so there is nothing to update there.

The one live concern

test/AuroraServerlessMySqlDriver.integration.js:36 — already carries an open thread from an earlier round; @ovr replied accepting the break, so I did not re-post it and instead replied on the thread with the part not yet considered: the break covers more than sslEnabled. v2's ClientConfiguration also took accessKeyId / secretAccessKey / sessionToken / maxRetries / httpOptions at the top level, and v3 ignores unknown constructor keys — so a plain-JS cube.js that passed credentials that way now fails at query time with CredentialsProviderError: Could not load credentials from any providers instead of erroring on the config. TS users are covered by the type swap; JS users are not. A changelog note listing the moved keys (or a constructor shim when options.accessKeyId is set) closes it.

Review threads

3 of my own threads were returned by the listing; 2 resolved, 1 left open and re-affirmed.

• Resolved PRRT_kwDOCOH19M6jADoE (stale @types/data-api-client) — fixed in 11bcd77, dep and lockfile entries both gone.
• Resolved PRRT_kwDOCOH19M6jAD4X (duplicated AWS SDK v3 core trees) — the floor is unchanged but the parallel subtrees the comment listed have merged to single versions.
• Left open PRRT_kwDOCOH19M6jADNQ (integration.js:36) — a human replied there, so resolution is the reviewer's call.

· [`cherry-pick-135a6d3-as-feat`](https://github.com/cube-js/cube/tree/cherry-pick-135a6d3-as-feat)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.67%. Comparing base (20f36e9) to head (11bcd77).

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #11904   +/-   ##
=======================================
  Coverage   60.67%   60.67%           
=======================================
  Files         240      240           
  Lines       19297    19297           
  Branches     3914     3914           
=======================================
  Hits        11709    11709           
  Misses       7040     7040           
  Partials      548      548           

Flag	Coverage Δ
cube-backend	60.67% <ø> (ø)

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.