chore: version packages

[github-actions]

Release Instructions

To complete this release:

1. Read the version bumps and changelogs below.
2. Go to the bottom of this PR.
3. Approve the workflow runs.
4. Wait until all checks pass.
5. Merge the PR.

The merge starts the npm publish.

---

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@aws-blocks/bb-data@0.2.5

Patch Changes

• e4b1498: Retry PGlite's WASM initialization on the intermittent _pg_initdb unreachable trap.

  PGlite defers initdb to the first query, which can trap with unreachable under memory pressure (notably on CI when several PGlite-backed dev servers boot concurrently) and kill the dev server mid-runMigrations. PGliteEngine (bb-data) and DsqlMockEngine (bb-distributed-data) now force initialization through a shared bounded retry (initializePgliteWithRetry in data-common) that closes the aborted WASM instance and boots a fresh one, so a transient init trap recovers instead of crashing the process.

• Updated dependencies [e4b1498]

• Updated dependencies [5071079]

• Updated dependencies [8966cfb]

• Updated dependencies [b11a75b]

  • @aws-blocks/data-common@0.1.4
  • @aws-blocks/core@0.1.19

@aws-blocks/bb-distributed-data@0.1.6

Patch Changes

• e4b1498: Retry PGlite's WASM initialization on the intermittent _pg_initdb unreachable trap.

  PGlite defers initdb to the first query, which can trap with unreachable under memory pressure (notably on CI when several PGlite-backed dev servers boot concurrently) and kill the dev server mid-runMigrations. PGliteEngine (bb-data) and DsqlMockEngine (bb-distributed-data) now force initialization through a shared bounded retry (initializePgliteWithRetry in data-common) that closes the aborted WASM instance and boots a fresh one, so a transient init trap recovers instead of crashing the process.

• Updated dependencies [e4b1498]

• Updated dependencies [5071079]

• Updated dependencies [8966cfb]

• Updated dependencies [b11a75b]

  • @aws-blocks/data-common@0.1.4
  • @aws-blocks/core@0.1.19

@aws-blocks/blocks@0.2.8

Patch Changes

• e4b1498: Retry PGlite's WASM initialization on the intermittent _pg_initdb unreachable trap.

  PGlite defers initdb to the first query, which can trap with unreachable under memory pressure (notably on CI when several PGlite-backed dev servers boot concurrently) and kill the dev server mid-runMigrations. PGliteEngine (bb-data) and DsqlMockEngine (bb-distributed-data) now force initialization through a shared bounded retry (initializePgliteWithRetry in data-common) that closes the aborted WASM instance and boots a fresh one, so a transient init trap recovers instead of crashing the process.

• 8966cfb: fix(telemetry): detect Render and Taskcluster as CI

  Telemetry CI detection (isCI()) checked a fixed list of CI env vars but
  omitted Render and Taskcluster. Render sets RENDER=true on every build and
  service; Taskcluster tasks always set the namespaced TASKCLUSTER_ROOT_URL.
  Runs on those platforms were therefore reported as real user sessions instead
  of ci:true, inflating user metrics. RENDER and TASKCLUSTER_ROOT_URL are
  now included in both isCI() implementations (@aws-blocks/core and
  @aws-blocks/create-blocks-app). The umbrella @aws-blocks/blocks gets a patch
  bump because it re-exports @aws-blocks/core.

• Updated dependencies [e4b1498]

• Updated dependencies [5071079]

• Updated dependencies [8966cfb]

• Updated dependencies [b11a75b]

  • @aws-blocks/bb-data@0.2.5
  • @aws-blocks/bb-distributed-data@0.1.6
  • @aws-blocks/core@0.1.19

@aws-blocks/core@0.1.19

Patch Changes

• 5071079: fix(core): make SandboxDisableDeletionProtection actually disable DynamoDB deletion protection

  The mixin duck-typed only on the deletionProtection property name, but the
  DynamoDB L1 CfnTable behind an L2 Table spells it
  deletionProtectionEnabled — and the L2 Table never re-exposes the prop. As a
  result the mixin silently never matched DynamoDB tables: sandbox stacks synthed
  DeletionProtectionEnabled: true and sandbox:destroy failed on every
  protected table, because DynamoDB refuses DeleteTable while protection is on
  regardless of the CloudFormation DeletionPolicy.

  The mixin now matches both the deletionProtection and
  deletionProtectionEnabled spellings, so DynamoDB tables are cleared through
  their L1 and consumers no longer need a local CfnTable workaround loop.
  Behavior for other resource types is unchanged: only explicitly-enabled
  protection is flipped, so unprotected resources still omit the property (Aurora
  DB instances continue to synth without DeletionProtection).

• 8966cfb: fix(telemetry): detect Render and Taskcluster as CI

  Telemetry CI detection (isCI()) checked a fixed list of CI env vars but
  omitted Render and Taskcluster. Render sets RENDER=true on every build and
  service; Taskcluster tasks always set the namespaced TASKCLUSTER_ROOT_URL.
  Runs on those platforms were therefore reported as real user sessions instead
  of ci:true, inflating user metrics. RENDER and TASKCLUSTER_ROOT_URL are
  now included in both isCI() implementations (@aws-blocks/core and
  @aws-blocks/create-blocks-app). The umbrella @aws-blocks/blocks gets a patch
  bump because it re-exports @aws-blocks/core.

• b11a75b: Reject primitive and null JSON-RPC params with the standard Invalid Params error.

• Updated dependencies [940956e]

  • @aws-blocks/hosting@0.1.9

@aws-blocks/create-blocks-app@0.1.20

Patch Changes

• 6918752: Use the lazy Lambda handler factory in the React template.

• 8966cfb: fix(telemetry): detect Render and Taskcluster as CI

  Telemetry CI detection (isCI()) checked a fixed list of CI env vars but
  omitted Render and Taskcluster. Render sets RENDER=true on every build and
  service; Taskcluster tasks always set the namespaced TASKCLUSTER_ROOT_URL.
  Runs on those platforms were therefore reported as real user sessions instead
  of ci:true, inflating user metrics. RENDER and TASKCLUSTER_ROOT_URL are
  now included in both isCI() implementations (@aws-blocks/core and
  @aws-blocks/create-blocks-app). The umbrella @aws-blocks/blocks gets a patch
  bump because it re-exports @aws-blocks/core.

@aws-blocks/data-common@0.1.4

Patch Changes

• e4b1498: Retry PGlite's WASM initialization on the intermittent _pg_initdb unreachable trap.

  PGlite defers initdb to the first query, which can trap with unreachable under memory pressure (notably on CI when several PGlite-backed dev servers boot concurrently) and kill the dev server mid-runMigrations. PGliteEngine (bb-data) and DsqlMockEngine (bb-distributed-data) now force initialization through a shared bounded retry (initializePgliteWithRetry in data-common) that closes the aborted WASM instance and boots a fresh one, so a transient init trap recovers instead of crashing the process.

@aws-blocks/hosting@0.1.9

Patch Changes

• 940956e: fix(hosting): encrypt the alarm SNS topic by default, with a key policy CloudWatch can actually use

  The monitoring construct's auto-created alarm topic was unencrypted. It now gets
  a dedicated customer-managed KMS key (MonitoringAlarmTopicKey) whose policy
  grants cloudwatch.amazonaws.com kms:Decrypt + kms:GenerateDataKey* in
  addition to the usual account-root administration statement.

  Both halves matter. Encrypting the topic makes hosting secure-by-default, and
  the CloudWatch grant is what keeps alarms working once it is encrypted: when an
  SNS topic used as a CloudWatch alarm action is KMS-encrypted, the key policy
  must grant the cloudwatch.amazonaws.com service principal, because CloudWatch
  calls KMS directly (not via SNS) and an account-root kms:* statement does
  not cover AWS service principals. Without the grant, CloudWatch's publish fails
  with KMSAccessDenied and notifications are dropped silently — the alarm still
  transitions to ALARM in the console, so the only symptom is the notification
  that never arrives.

  An AWS-managed key (alias/aws/sns) cannot be used instead: its key policy is
  not editable and does not grant CloudWatch, so a customer-managed key is the
  only option that can carry the grant.

  The grant is scoped to just those two actions for that one service principal on
  a single-purpose key, plus a StringEqualsIfExists guard on aws:SourceAccount
  against cross-account confused-deputy use. IfExists is deliberate:
  aws:SourceAccount is only populated on direct service-principal calls, and a
  hard StringEquals would reintroduce the very silent deny this grant exists to
  prevent.

  No configuration changes: encryption is unconditional, with no opt-out knob to
  weaken it. The only API addition is a read-only encryptionKey accessor on
  MonitoringConstruct, alongside the existing topic and alarms, so callers
  can grant additional publishers on the key. Callers who need different key
  management continue to pass their own snsTopic / snsTopicArn and own that
  topic's encryption. Note the KMS key adds roughly $1/month per stack, and
  monitoring is on by default; monitoring: { enabled: false } or a BYO topic
  avoids it.