fix(deploy): bump @aws-cdk/toolkit-lib to read cloud-assembly schema 54#1465
Merged
Conversation
aws-cdk-lib@2.258.0 (published 2026-06-04) bundles
cloud-assembly-schema ^54.0.0, so freshly-created CDK projects now write
schema-54 manifests. The CLI's bundled @aws-cdk/toolkit-lib@1.24.0 reads
only up to schema 53, so synth fails with AssemblyVersionMismatch
("Maximum schema version supported is 53.x.x, but found 54.0.0").
Bump @aws-cdk/toolkit-lib ^1.16.0 -> ^1.28.0 (resolves the bundled reader
to 1.28.0, whose nested cloud-assembly-schema is 54.2.0) and regenerate
npm-shrinkwrap.json. 1.28.0 reads schema 54 and all of 53 — forward
compatible — and is an API-compatible drop-in (no source changes).
Also bump the generated template's aws-cdk devDep 2.1100.1 -> 2.1126.0 so
the manual `npm run cdk` escape hatch can also read schema 54.
Verified by reproducing the customer scenario: a fresh project resolving
aws-cdk-lib@2.258.0 writes a 54.0.0 manifest, and `agentcore deploy
--dry-run` now synthesizes cleanly (Synthesize CloudFormation: SUCCESS).
Contributor
|
Claude Security Review: no high-confidence findings. (run) |
Contributor
Package TarballHow to installgh release download pr-1465-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.17.0.tgz |
Contributor
Coverage Report
|
agentcore-cli-automation
approved these changes
Jun 5, 2026
agentcore-cli-automation
left a comment
There was a problem hiding this comment.
Looks good to merge.
Verified the key claims independently:
- Cross-checked the npm registry for
@aws-cdk/toolkit-lib:1.28.0is indeed the first version whose@aws-cdk/cloud-assembly-schemapeer/dep is>=54.x(1.27.0and earlier all top out at>=53.x), so the bump is the minimal version that resolves the writer=54 / reader-max=53 mismatch. - The toolkit-lib API surface used in
src/cli/cdk/toolkit-lib/wrapper.tsandsrc/cli/operations/deploy/teardown.ts(Toolkit,fromCdkApp,fromAssemblyDirectory,synth,deploy,destroy,bootstrap,BaseCredentials,BootstrapEnvironments,BootstrapStackParameters,StackSelectionStrategy,IIoHost,ICloudAssemblySource) is all stable across 1.24→1.28, so no source changes needed matches the diff. - Shrinkwrap update is internally consistent (toolkit-lib's nested
cloud-assembly-schema@54.2.0,cloud-assembly-api@2.2.5,cdk-from-cfnandsemverbumps;uuidremoval is no longer a transitive dep of toolkit-lib at 1.28.0). - Template
aws-cdkdevDep bump (2.1100.1→2.1126.0) and the matching snapshot update are aligned.
Non-blocking observation (not for this PR): the structural ^2.248.0 caret on aws-cdk-lib in src/assets/cdk/package.json plus no committed lockfile in the template means the same writer/reader skew will recur the next time AWS bumps the assembly schema. Worth tracking separately (e.g. tighter pin in the template, ship a lockfile, or wire Dependabot to keep @aws-cdk/toolkit-lib rolling), but doesn't need to gate this fix.
jariy17
approved these changes
Jun 5, 2026
Contributor
jariy17
left a comment
There was a problem hiding this comment.
Verified the upgrading cloud assembly schema doesn't introduce breaking changes to the cli.
7 tasks
jariy17
added a commit
that referenced
this pull request
Jun 5, 2026
…ifests PR #1465 fixed the synth-time reader (@aws-cdk/toolkit-lib 1.16 -> 1.28) but the asset-publish phase uses a separate package, @aws-cdk/cdk-assets-lib, that was still pinned to 1.4.2 in the shrinkwrap. 1.4.2's @aws-cdk/cloud-assembly-schema floor is >=53.8.0 — it cannot read schema 54 asset manifests written by aws-cdk-lib@2.258.0+. Symptom: e2e (main, 6/6) failed after the rerun of #1465 with "Cannot read asset manifest 'cdk.out/...assets.json': Cloud assembly schema version mismatch: Maximum schema version supported is 53.x.x, but found 54.0.0" on byo-custom-jwt deploy. (Dataset tests passed because dataset stacks have no file/zip/docker assets.) Adding @aws-cdk/cdk-assets-lib as a direct dependency at ^1.4.10 forces the shrinkwrap to resolve the asset-publisher reader to a version whose cloud-assembly-schema floor is >=54.2.0. toolkit-lib's wide ^1 transitive range was insufficient to upgrade past 1.4.2 during the previous regen. Verified locally: end-to-end agentcore deploy of a BYO Strands agent against aws-cdk-lib@2.258.0 (writes schema 54) now succeeds — synth, asset publish, CFN deploy all pass.
6 tasks
jariy17
added a commit
that referenced
this pull request
Jun 5, 2026
…ifests (#1468) PR #1465 fixed the synth-time reader (@aws-cdk/toolkit-lib 1.16 -> 1.28) but the asset-publish phase uses a separate package, @aws-cdk/cdk-assets-lib, that was still pinned to 1.4.2 in the shrinkwrap. 1.4.2's @aws-cdk/cloud-assembly-schema floor is >=53.8.0 — it cannot read schema 54 asset manifests written by aws-cdk-lib@2.258.0+. Symptom: e2e (main, 6/6) failed after the rerun of #1465 with "Cannot read asset manifest 'cdk.out/...assets.json': Cloud assembly schema version mismatch: Maximum schema version supported is 53.x.x, but found 54.0.0" on byo-custom-jwt deploy. (Dataset tests passed because dataset stacks have no file/zip/docker assets.) Adding @aws-cdk/cdk-assets-lib as a direct dependency at ^1.4.10 forces the shrinkwrap to resolve the asset-publisher reader to a version whose cloud-assembly-schema floor is >=54.2.0. toolkit-lib's wide ^1 transitive range was insufficient to upgrade past 1.4.2 during the previous regen. Verified locally: end-to-end agentcore deploy of a BYO Strands agent against aws-cdk-lib@2.258.0 (writes schema 54) now succeeds — synth, asset publish, CFN deploy all pass.
9 tasks
jariy17
added a commit
that referenced
this pull request
Jun 5, 2026
…solution (#1469) PRs #1465 and #1468 fixed the bundled CLI's readers (toolkit-lib + cdk-assets-lib) to handle schema 54. Customer deploys via the global CLI install work correctly. However, the e2e test `byo-custom-jwt.test.ts` uses `runLocalCLI`, which spawns `node dist/cli/index.mjs` from the workspace root. From there, Node's module resolution sees the workspace's own `aws-cdk-lib: ^2.248.0` (resolved to 2.257.0) which has a peer-dep `cloud-assembly-schema: ^53.25.0`, hoisting schema 53.28.0 at the top level. `@aws-cdk/cloud-assembly-api` (also hoisted) binds to that top-level schema rather than the nested 54.2.0 copies under toolkit-lib and cdk-assets-lib — so synth still throws AssemblyVersionMismatch in CI. Bumping aws-cdk-lib from ^2.248.0 to ^2.258.0 makes its peer-dep `cloud-assembly-schema: ^54.0.0`, allowing schema 54.2.0 to hoist top-level and cloud-assembly-api to bind to it. Verified: byo-custom-jwt deploy assertion now passes locally against aws-cdk-lib@2.258.0 (writes schema 54). End-user CLI behavior is unchanged (global install resolution was already correct after #1465/#1468).
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
agentcore deployfails at the Synthesize CloudFormation step for freshly-created projects:Root cause — a frozen reader paired with a floating writer:
aws-cdk-lib: ^2.248.0(no lockfile), sonpm installresolves the newest match.aws-cdk-lib@2.258.0, which bundlescloud-assembly-schema@^54.0.0. Fresh projects now write schema-54 manifests.@aws-cdk/toolkit-lib@1.24.0(frozen bynpm-shrinkwrap.json) reads only up to schema 53.AssemblyVersionMismatch.Registry-verified boundary:
cloud-assembly-schemaaws-cdk-lib@2.257.0^53.25.0aws-cdk-lib@2.258.0^54.0.0@aws-cdk/toolkit-lib@1.24.0(current)@aws-cdk/toolkit-lib@1.27.0>=53.28.0(max 53)@aws-cdk/toolkit-lib@1.28.0>=54.2.0This matches customer reports:
aws-cdk-lib@2.257.0deploys,2.258.0fails, same CLI (0.17.0).Changes
package.json:@aws-cdk/toolkit-lib^1.16.0→^1.28.0. Regeneratingnpm-shrinkwrap.jsonresolves the bundled reader to1.28.0, whose nestedcloud-assembly-schemais54.2.0(reads schema 54 + all of 53 — forward compatible). API-compatible drop-in: every toolkit-lib API the CLI uses (Toolkit,synth,fromCdkApp,deploy/destroy/bootstrap,StackSelectionStrategy) is byte-identical or only additively changed across1.24.0→1.28.0, so no source changes.src/assets/cdk/package.json: templateaws-cdkdevDep2.1100.1→2.1126.0, so the manualnpm run cdkescape hatch also reads schema 54.assets.snapshot.test.ts.snap: updated for the template version bump.No change needed to
@aws/agentcore-cdk(L3 constructs) — it declaresaws-cdk-libonly as a caret peer dependency and never reads/writes the cloud-assembly manifest.Type of Change
Testing
Reproduced the customer scenario end-to-end against the patched CLI:
agentcore create→ generated CDK app resolvesaws-cdk-lib@2.258.0, which writes a54.0.0manifest (cdk.out/manifest.json).agentcore deploy --dry-run→ Synthesize CloudFormation: SUCCESS (the exact step that previously threwAssemblyVersionMismatch), no schema errors in the deploy log.toolkit-lib@1.28.0loadscloud-assembly-schema@54.2.0(reader 54.2.0 ≥ writer 54.0.0).npm run test:unit(240 deploy/cdk/error tests pass) andnpm run test:integnpm run typechecknpm run lint(0 errors)src/assets/, rannpm run test:update-snapshots, and committed the updated snapshotChecklist