cdk-preflight 0.0.50 → 0.0.52

package/.jsii

@@ -9415,7 +9415,7 @@
   },
   "name": "cdk-preflight",
   "readme": {
-    "markdown": "<p align=\"center\">\n  <img src=\"https://raw.githubusercontent.com/badmintoncryer/cdk-preflight/main/assets/logo.png\" alt=\"cdk-preflight\" width=\"104\" height=\"104\">\n</p>\n\n<h1 align=\"center\">cdk-preflight</h1>\n\n<p align=\"center\">\n  <strong>Catch deploy-time CloudFormation failures at <code>cdk synth</code> time.</strong>\n</p>\n\n<p align=\"center\">\n  <a href=\"https://github.com/badmintoncryer/cdk-preflight/actions/workflows/monthly-verify.yml\"><img src=\"https://github.com/badmintoncryer/cdk-preflight/actions/workflows/monthly-verify.yml/badge.svg\" alt=\"monthly real-deploy verification\"></a>\n  <a href=\"https://www.npmjs.com/package/cdk-preflight\"><img src=\"https://img.shields.io/npm/v/cdk-preflight.svg\" alt=\"npm version\"></a>\n</p>\n\nSome CloudFormation constraints are not expressed in resource provider schemas — they live only in documentation, in service API validation, or across multiple properties. Templates that violate them pass `cdk synth`, pass CloudFormation pre-deployment validation, and then fail minutes into a deployment, burning a rollback cycle.\n\ncdk-preflight is a curated [Rego rule pack](docs/rules.md) for exactly those constraints, evaluated with the CloudFormation validation engine that ships inside `aws-cdk-lib` (>= 2.267.0). By default a violation **fails `cdk synth`** — a template that is known to fail at deploy time never leaves your machine.\n\nThe pack aims at **every deploy-time failure that no existing CDK mechanism already catches** — nothing narrower. Every bundled rule is backed by a `fail`/`pass` template pair, and the failure has been reproduced against real AWS (or is explicitly marked `doc-only`). Rules that the built-in validation engine already covers are deliberately **not** duplicated — a test suite enforces this.\n\n> **Requires `aws-cdk-lib` >= 2.267.0** (released 2026-08-27) — the first release that bundles\n> the CloudFormation validation engine. On older versions the rules cannot run at all.\n\n## Quick start\n\n```bash\nnpm i -D cdk-preflight\nnpx cdkpf init   # inserts Preflight.apply(app) into your CDK app\n                         # (`npx cdkpf init` is the same command, shorter)\n```\n\nor add one line yourself:\n\n```ts\nimport { Preflight } from 'cdk-preflight';\n\nconst app = new App();\nPreflight.apply(app);\n```\n\nOn violation, `cdk synth` fails with one error per finding, including the construct trace:\n\n```text\nERROR idle_timeout.timeout_seconds is 5000 but must be between 1 and 4000 seconds (cdk-preflight)\n   MyStack/Alb/Resource (Alb16C2F182) aws-cdk-lib.aws_elasticloadbalancingv2.CfnLoadBalancer\n\nSynthesis finished with errors\n```\n\n## Observe-only mode\n\nTo roll the rules out gradually, start with `enforce: false`: findings then surface as synth **warnings** through the CDK built-in validator, with construct traces and per-finding acknowledgement:\n\n```ts\nPreflight.apply(app, { enforce: false });\n```\n\n```text\nWARNING idle_timeout.timeout_seconds is 5000 but must be between 1 and 4000 seconds (CloudFormation Validate)\n   MyStack/Alb (Alb) aws-cdk-lib.aws_elasticloadbalancingv2.CfnLoadBalancer\n   Acknowledge with 'CloudFormation-Validate::pf-elbv2-lb-idle-timeout-range'\n```\n\n> **Known limitation with stages.** The AWS CDK CLI drops validation findings for stacks nested in a `Stage`\n> before printing them, so in observe-only mode those findings appear **only** in `cdk.out/validation-report.json`\n> and never on the console. Enforce mode is not affected: cdk-preflight reports such findings itself and fails\n> synthesis. This is a CLI-side bug (present since aws-cdk 2.1128.1), not a rule evaluation problem.\n\n| Option | Default | Effect |\n|---|---|---|\n| `enforce` | `true` | Violations of bundled rules fail synthesis; set to `false` to only warn |\n| `strict` | `false` | With `enforce`: also fail on error-class findings (`ERROR`/`FATAL`, e.g. `F3034`) of the built-in validation engine itself, which the CDK currently downgrades to warnings |\n| `exclude` | `[]` | Rule ids to disable |\n| `includeUpstreamPending` | `true` | Include rules already proposed to the upstream engine but not yet merged |\n\nTo opt out of a single rule, pass its id in `exclude`. In observe-only mode, individual findings can also be suppressed with the CDK acknowledge mechanism shown in the warning text.\n\n## Bundled rules\n\nSee [docs/rules.md](docs/rules.md) for the generated rule table. Highlights:\n\n- **ELBv2**: `idle_timeout` / `deregistration_delay` / `slow_start` attribute ranges (stringly-typed Key/Value attributes are invisible to schema validation)\n- **IAM**: managed (6,144 chars) and inline (role/group/user) policy document size limits\n- **CloudFront**: `MinTTL <= DefaultTTL <= MaxTTL` ordering, ACM certificates must live in `us-east-1`\n- **Step Functions**: `Next`/`Default`/`Choices` must reference defined states (a dangling `StartAt` is already caught by the engine's built-in `E3601`)\n- **EC2**: security group TCP/UDP port ranges and `FromPort <= ToPort`\n\n## For AI agents\n\nTo add cdk-preflight to a CDK app:\n\n1. `npm i -D cdk-preflight`\n2. `npx cdk-preflight init` — or the shorter alias `npx cdkpf init` (finds the entry point via `cdk.json` and inserts `Preflight.apply(app)`; use `--dry-run` to preview)\n3. Run `cdk synth`. Violations fail the synth with a validation report; each finding carries a rule id, the actual value, and a suggested fix\n4. To fix a finding, prefer correcting the resource. To opt out instead: `exclude: ['<rule-id>']` disables one rule, `enforce: false` switches to warn-only reporting\n\nThe machine-readable findings are written to `cdk.out/validation-report.json` when synthesizing with `-c @aws-cdk/core:validationReportJson=true`.\n\n### Report missed deploy errors\n\ncdk-preflight only knows the failure modes it has benched. When a deploy fails on a constraint the pack should have caught, that report is how new rules get added — but at that moment cdk-preflight is out of the loop (it passed the synth), so the instruction has to already sit in your agent's context. Paste this into your repository's `AGENTS.md` (or `CLAUDE.md`):\n\n```markdown\n## cdk-preflight: report missed deploy errors\n\nIf `cdk deploy` fails even though `cdk synth` (with cdk-preflight enabled) passed,\nand the failure is a service-side validation rejection — CREATE_FAILED/UPDATE_FAILED\nwith a 400-class message such as \"Invalid request provided: ...\" — cdk-preflight is\nmissing a rule. Report it:\n\n1. Qualify first. NOT reportable: AccessDenied / permissions, service quotas,\n   throttling, name conflicts with existing resources, stabilization timeouts.\n2. Redact account-specific data (account IDs -> 123456789012, real ARNs/domains\n   -> placeholders).\n3. Search existing issues: https://github.com/badmintoncryer/cdk-preflight/issues\n4. With your user's approval, open a \"Missed deploy error\" issue with the verbatim\n   error message, the resource type, a minimal template snippet, and your\n   aws-cdk-lib / cdk-preflight versions.\n```\n\n## Scope and rule lifecycle\n\nA constraint belongs in the pack when violating it makes a real deployment fail *and* no layer that sees the same synthesized template already blocks it. There is no further \"is this worth a rule\" question — if the gap is real, it gets a rule.\n\nCDK L2 construct validation is deliberately **not** one of those layers. `CfnXxx` usage, escape hatches, `addPropertyOverride`, `cloudformation-include` and migrated templates all bypass L2, so an L2 guard covering the same mistake neither disqualifies a rule nor retires one.\n\nThat makes growth the normal state, and it has a consequence worth knowing before you upgrade: **new rules land in minor releases, so a minor upgrade can newly fail a `cdk synth` that passed yesterday.** That is intended, not a regression. If you need a frozen rule set, pin the version; to drop a single rule, `exclude: ['<rule-id>']`; to see everything without failing the build, `enforce: false`.\n\nRules move the other way too. Once the validation engine bundled in `aws-cdk-lib` (or CloudFormation's own pre-deploy validation) starts blocking a constraint, the rule is deleted rather than kept as a duplicate — staying on an older `aws-cdk-lib` and an older cdk-preflight keeps the old behavior.\n\n## How it works\n\n`Preflight.apply()` evaluates the rules with the [cloudformation-validate](https://github.com/aws-cloudformation/cloudformation-validate) Rust/WASM engine that ships inside `aws-cdk-lib` — no extra binaries, no network access at synth time. In the default enforce mode the engine is invoked through a dedicated CDK validation plugin so that violations fail synthesis; with `enforce: false` the rules are instead injected into the CDK built-in `CloudFormationValidatePlugin` and reported as warnings.\n\nConstraints that *can* be expressed in schemas or generic engine rules also make good upstream PRs to that engine, but nothing here waits on one — the upstream release cycle is deliberately slower than this pack's. Each rule's `meta.yaml` tracks its upstream status so that retirement stays bookkeeping.\n\n## Requirements\n\n- `aws-cdk-lib` >= 2.267.0, released 2026-08-27 (the first release that bundles the built-in CloudFormation validator). This is a recent release — an existing CDK app may need an upgrade before cdk-preflight can run.\n\n## Contributing\n\nRule authoring, the verification gates (including real-deploy reproduction), and the test layout are documented in [AGENTS.md](AGENTS.md) — written for AI coding agents and humans alike.\n\n## License\n\nApache-2.0\n"
+    "markdown": "<p align=\"center\">\n  <img src=\"https://raw.githubusercontent.com/badmintoncryer/cdk-preflight/main/assets/logo.png\" alt=\"cdk-preflight\" width=\"104\" height=\"104\">\n</p>\n\n<h1 align=\"center\">cdk-preflight</h1>\n\n<p align=\"center\">\n  <strong>Catch deploy-time CloudFormation failures at <code>cdk synth</code> time.</strong>\n</p>\n\n<p align=\"center\">\n  <a href=\"https://github.com/badmintoncryer/cdk-preflight/actions/workflows/monthly-verify.yml\"><img src=\"https://github.com/badmintoncryer/cdk-preflight/actions/workflows/monthly-verify.yml/badge.svg\" alt=\"monthly real-deploy verification\"></a>\n  <a href=\"https://www.npmjs.com/package/cdk-preflight\"><img src=\"https://img.shields.io/npm/v/cdk-preflight.svg\" alt=\"npm version\"></a>\n  <a href=\"https://www.npmjs.com/package/cdk-preflight\"><img src=\"https://img.shields.io/npm/dt/cdk-preflight.svg\" alt=\"npm total downloads\"></a>\n</p>\n\nSome CloudFormation constraints are not expressed in resource provider schemas — they live only in documentation, in service API validation, or across multiple properties. Templates that violate them pass `cdk synth`, pass CloudFormation pre-deployment validation, and then fail minutes into a deployment, burning a rollback cycle.\n\ncdk-preflight is a curated [Rego rule pack](docs/rules.md) for exactly those constraints, evaluated with the CloudFormation validation engine that ships inside `aws-cdk-lib` (>= 2.267.0). By default a violation **fails `cdk synth`** — a template that is known to fail at deploy time never leaves your machine.\n\nThe pack aims at **every deploy-time failure that no existing CDK mechanism already catches** — nothing narrower. Every bundled rule is backed by a `fail`/`pass` template pair, and the failure has been reproduced against real AWS (or is explicitly marked `doc-only`). Rules that the built-in validation engine already covers are deliberately **not** duplicated — a test suite enforces this.\n\n> **Requires `aws-cdk-lib` >= 2.267.0** (released 2026-08-27) — the first release that bundles\n> the CloudFormation validation engine. On older versions the rules cannot run at all.\n\n## Quick start\n\n```bash\nnpm i -D cdk-preflight\nnpx cdkpf init   # inserts Preflight.apply(app) into your CDK app\n                         # (`npx cdkpf init` is the same command, shorter)\n```\n\nor add one line yourself:\n\n```ts\nimport { Preflight } from 'cdk-preflight';\n\nconst app = new App();\nPreflight.apply(app);\n```\n\nOn violation, `cdk synth` fails with one error per finding, including the construct trace:\n\n```text\nERROR idle_timeout.timeout_seconds is 5000 but must be between 1 and 4000 seconds (cdk-preflight)\n   MyStack/Alb/Resource (Alb16C2F182) aws-cdk-lib.aws_elasticloadbalancingv2.CfnLoadBalancer\n\nSynthesis finished with errors\n```\n\n## Observe-only mode\n\nTo roll the rules out gradually, start with `enforce: false`: findings then surface as synth **warnings** through the CDK built-in validator, with construct traces and per-finding acknowledgement:\n\n```ts\nPreflight.apply(app, { enforce: false });\n```\n\n```text\nWARNING idle_timeout.timeout_seconds is 5000 but must be between 1 and 4000 seconds (CloudFormation Validate)\n   MyStack/Alb (Alb) aws-cdk-lib.aws_elasticloadbalancingv2.CfnLoadBalancer\n   Acknowledge with 'CloudFormation-Validate::pf-elbv2-lb-idle-timeout-range'\n```\n\n> **Known limitation with stages.** The AWS CDK CLI drops validation findings for stacks nested in a `Stage`\n> before printing them, so in observe-only mode those findings appear **only** in `cdk.out/validation-report.json`\n> and never on the console. Enforce mode is not affected: cdk-preflight reports such findings itself and fails\n> synthesis. This is a CLI-side bug (present since aws-cdk 2.1128.1), not a rule evaluation problem.\n\n| Option | Default | Effect |\n|---|---|---|\n| `enforce` | `true` | Violations of bundled rules fail synthesis; set to `false` to only warn |\n| `strict` | `false` | With `enforce`: also fail on error-class findings (`ERROR`/`FATAL`, e.g. `F3034`) of the built-in validation engine itself, which the CDK currently downgrades to warnings |\n| `exclude` | `[]` | Rule ids to disable |\n| `includeUpstreamPending` | `true` | Include rules already proposed to the upstream engine but not yet merged |\n\nTo opt out of a single rule, pass its id in `exclude`. In observe-only mode, individual findings can also be suppressed with the CDK acknowledge mechanism shown in the warning text.\n\n## Bundled rules\n\nSee [docs/rules.md](docs/rules.md) for the generated rule table. Highlights:\n\n- **ELBv2**: `idle_timeout` / `deregistration_delay` / `slow_start` attribute ranges (stringly-typed Key/Value attributes are invisible to schema validation)\n- **IAM**: managed (6,144 chars) and inline (role/group/user) policy document size limits\n- **CloudFront**: `MinTTL <= DefaultTTL <= MaxTTL` ordering, ACM certificates must live in `us-east-1`\n- **Step Functions**: `Next`/`Default`/`Choices` must reference defined states (a dangling `StartAt` is already caught by the engine's built-in `E3601`)\n- **EC2**: security group TCP/UDP port ranges and `FromPort <= ToPort`\n\n## For AI agents\n\nTo add cdk-preflight to a CDK app:\n\n1. `npm i -D cdk-preflight`\n2. `npx cdk-preflight init` — or the shorter alias `npx cdkpf init` (finds the entry point via `cdk.json` and inserts `Preflight.apply(app)`; use `--dry-run` to preview)\n3. Run `cdk synth`. Violations fail the synth with a validation report; each finding carries a rule id, the actual value, and a suggested fix\n4. To fix a finding, prefer correcting the resource. To opt out instead: `exclude: ['<rule-id>']` disables one rule, `enforce: false` switches to warn-only reporting\n\nThe machine-readable findings are written to `cdk.out/validation-report.json` when synthesizing with `-c @aws-cdk/core:validationReportJson=true`.\n\n### Report missed deploy errors\n\ncdk-preflight only knows the failure modes it has benched. When a deploy fails on a constraint the pack should have caught, that report is how new rules get added — but at that moment cdk-preflight is out of the loop (it passed the synth), so the instruction has to already sit in your agent's context. Paste this into your repository's `AGENTS.md` (or `CLAUDE.md`):\n\n```markdown\n## cdk-preflight: report missed deploy errors\n\nIf `cdk deploy` fails even though `cdk synth` (with cdk-preflight enabled) passed,\nand the failure is a service-side validation rejection — CREATE_FAILED/UPDATE_FAILED\nwith a 400-class message such as \"Invalid request provided: ...\" — cdk-preflight is\nmissing a rule. Report it:\n\n1. Qualify first. NOT reportable: AccessDenied / permissions, service quotas,\n   throttling, name conflicts with existing resources, stabilization timeouts.\n2. Redact account-specific data (account IDs -> 123456789012, real ARNs/domains\n   -> placeholders).\n3. Search existing issues: https://github.com/badmintoncryer/cdk-preflight/issues\n4. With your user's approval, open a \"Missed deploy error\" issue with the verbatim\n   error message, the resource type, a minimal template snippet, and your\n   aws-cdk-lib / cdk-preflight versions.\n```\n\n## Scope and rule lifecycle\n\nA constraint belongs in the pack when violating it makes a real deployment fail *and* no layer that sees the same synthesized template already blocks it. There is no further \"is this worth a rule\" question — if the gap is real, it gets a rule.\n\nCDK L2 construct validation is deliberately **not** one of those layers. `CfnXxx` usage, escape hatches, `addPropertyOverride`, `cloudformation-include` and migrated templates all bypass L2, so an L2 guard covering the same mistake neither disqualifies a rule nor retires one.\n\nThat makes growth the normal state, and it has a consequence worth knowing before you upgrade: **new rules land in minor releases, so a minor upgrade can newly fail a `cdk synth` that passed yesterday.** That is intended, not a regression. If you need a frozen rule set, pin the version; to drop a single rule, `exclude: ['<rule-id>']`; to see everything without failing the build, `enforce: false`.\n\nRules move the other way too. Once the validation engine bundled in `aws-cdk-lib` (or CloudFormation's own pre-deploy validation) starts blocking a constraint, the rule is deleted rather than kept as a duplicate — staying on an older `aws-cdk-lib` and an older cdk-preflight keeps the old behavior.\n\n## How it works\n\n`Preflight.apply()` evaluates the rules with the [cloudformation-validate](https://github.com/aws-cloudformation/cloudformation-validate) Rust/WASM engine that ships inside `aws-cdk-lib` — no extra binaries, no network access at synth time. In the default enforce mode the engine is invoked through a dedicated CDK validation plugin so that violations fail synthesis; with `enforce: false` the rules are instead injected into the CDK built-in `CloudFormationValidatePlugin` and reported as warnings.\n\nConstraints that *can* be expressed in schemas or generic engine rules also make good upstream PRs to that engine, but nothing here waits on one — the upstream release cycle is deliberately slower than this pack's. Each rule's `meta.yaml` tracks its upstream status so that retirement stays bookkeeping.\n\n## Requirements\n\n- `aws-cdk-lib` >= 2.267.0, released 2026-08-27 (the first release that bundles the built-in CloudFormation validator). This is a recent release — an existing CDK app may need an upgrade before cdk-preflight can run.\n\n## Contributing\n\nRule authoring, the verification gates (including real-deploy reproduction), and the test layout are documented in [AGENTS.md](AGENTS.md) — written for AI coding agents and humans alike.\n\n## License\n\nApache-2.0\n"
   },
   "repository": {
     "type": "git",
@@ -9599,6 +9599,6 @@
       "symbolId": "src/index:PreflightOptions"
     }
   },
-  "version": "0.0.50",
-  "fingerprint": "51USbg/2j8IzE+b/RpoBLT6WKHuY+bmaLoqQQXgmyZw="
+  "version": "0.0.52",
+  "fingerprint": "bN+TUVvujlD7FpGo4Oagl8iHyysAwlg58PCf8dJ/XoA="
 }

package/README.md

@@ -11,6 +11,7 @@
 <p align="center">
   <a href="https://github.com/badmintoncryer/cdk-preflight/actions/workflows/monthly-verify.yml"><img src="https://github.com/badmintoncryer/cdk-preflight/actions/workflows/monthly-verify.yml/badge.svg" alt="monthly real-deploy verification"></a>
   <a href="https://www.npmjs.com/package/cdk-preflight"><img src="https://img.shields.io/npm/v/cdk-preflight.svg" alt="npm version"></a>
+  <a href="https://www.npmjs.com/package/cdk-preflight"><img src="https://img.shields.io/npm/dt/cdk-preflight.svg" alt="npm total downloads"></a>
 </p>
 
 Some CloudFormation constraints are not expressed in resource provider schemas — they live only in documentation, in service API validation, or across multiple properties. Templates that violate them pass `cdk synth`, pass CloudFormation pre-deployment validation, and then fail minutes into a deployment, burning a rollback cycle.

package/docs/rules.md

@@ -395,8 +395,59 @@
 | `pf-lambda-efs-requires-vpc` | AWS::Lambda::Function | Mounting EFS requires VpcConfig | none |
 | `pf-lambda-env-size` | AWS::Lambda::Function | Lambda environment variables are limited to 4096 bytes in total | none |
 | `pf-lambda-esm-batchsize-window` | AWS::Lambda::EventSourceMapping | SQS batch sizes over 10 need a batching window | none |
+| `pf-lambda-esm-bisect-batch-stream-only` | AWS::Lambda::EventSourceMapping | BisectBatchOnFunctionError only applies to Kinesis and DynamoDB streams | none |
+| `pf-lambda-esm-client-certificate-kafka-only` | AWS::Lambda::EventSourceMapping | CLIENT_CERTIFICATE_TLS_AUTH is not accepted on Amazon MQ | none |
+| `pf-lambda-esm-ddb-at-timestamp-unsupported` | AWS::Lambda::EventSourceMapping | DynamoDB Streams rejects AT_TIMESTAMP | none |
+| `pf-lambda-esm-ddb-cross-region` | AWS::Lambda::EventSourceMapping | A DynamoDB stream source must sit in the deploy region | none |
+| `pf-lambda-esm-ddb-destination-standard-only` | AWS::Lambda::EventSourceMapping | An on-failure destination cannot be a FIFO queue or topic | none |
+| `pf-lambda-esm-destination-config-stream-only` | AWS::Lambda::EventSourceMapping | DestinationConfig only applies to stream sources | none |
+| `pf-lambda-esm-docdb-basic-auth-required` | AWS::Lambda::EventSourceMapping | A DocumentDB event source needs BASIC_AUTH credentials | none |
+| `pf-lambda-esm-docdb-cluster-type` | AWS::Lambda::EventSourceMapping | Elastic DocumentDB clusters cannot be event sources | none |
+| `pf-lambda-esm-docdb-database-name-required` | AWS::Lambda::EventSourceMapping | CollectionName needs DatabaseName | none |
+| `pf-lambda-esm-docdb-full-document-values` | AWS::Lambda::EventSourceMapping | FullDocument accepts only UpdateLookup and Default | pending-engine |
+| `pf-lambda-esm-documentdb-arn-rds-service` | AWS::Lambda::EventSourceMapping | A DocumentDB event source is named by its rds cluster ARN | none |
+| `pf-lambda-esm-event-source-arn-service` | AWS::Lambda::EventSourceMapping | EventSourceArn must name a supported event source service | none |
+| `pf-lambda-esm-fifo-batch-size-max` | AWS::Lambda::EventSourceMapping | A FIFO queue source caps BatchSize at 10 | none |
 | `pf-lambda-esm-fifo-batching-window` | AWS::Lambda::EventSourceMapping | FIFO queues reject a batching window | none |
+| `pf-lambda-esm-filter-criteria-docdb-unsupported` | AWS::Lambda::EventSourceMapping | DocumentDB event sources do not support FilterCriteria | none |
+| `pf-lambda-esm-filter-pattern-eventbridge-syntax` | AWS::Lambda::EventSourceMapping | A filter Pattern must be an EventBridge pattern JSON object | none |
+| `pf-lambda-esm-filter-pattern-leaf-array` | AWS::Lambda::EventSourceMapping | Every leaf value in a filter Pattern must be an array | none |
+| `pf-lambda-esm-filters-hard-limit-ten` | AWS::Lambda::EventSourceMapping | An event source mapping takes at most ten filters | none |
+| `pf-lambda-esm-function-name-bare-max-length` | AWS::Lambda::EventSourceMapping | A bare function name in FunctionName is limited to 64 characters | none |
+| `pf-lambda-esm-function-name-format` | AWS::Lambda::EventSourceMapping | FunctionName must be a name, ARN, partial ARN or version/alias ARN | none |
+| `pf-lambda-esm-function-response-types-allowed-value` | AWS::Lambda::EventSourceMapping | FunctionResponseTypes only accepts ReportBatchItemFailures | pending-engine |
+| `pf-lambda-esm-function-response-types-mq-docdb` | AWS::Lambda::EventSourceMapping | Partial batch failure reporting is not available on Amazon MQ or DocumentDB | none |
+| `pf-lambda-esm-kms-key-policy-lambda-principal` | AWS::Lambda::EventSourceMapping<br>AWS::KMS::Key | The filter-criteria key policy must let Lambda decrypt | none |
+| `pf-lambda-esm-logging-config-kafka-only` | AWS::Lambda::EventSourceMapping | LoggingConfig only applies to Kafka sources | none |
+| `pf-lambda-esm-max-concurrency-vs-reserved` | AWS::Lambda::EventSourceMapping<br>AWS::Lambda::Function | MaximumConcurrency cannot exceed the reserved concurrency of the function | none |
+| `pf-lambda-esm-maximum-record-age-stream-only` | AWS::Lambda::EventSourceMapping | MaximumRecordAgeInSeconds only applies to stream sources | none |
+| `pf-lambda-esm-maximum-retry-attempts-stream-only` | AWS::Lambda::EventSourceMapping | MaximumRetryAttempts only applies to stream sources | none |
+| `pf-lambda-esm-metrics-allowed-values` | AWS::Lambda::EventSourceMapping | MetricsConfig.Metrics only accepts EventCount, ErrorCount and KafkaMetrics | pending-engine |
+| `pf-lambda-esm-metrics-error-count-kafka-only` | AWS::Lambda::EventSourceMapping | The ErrorCount metric is Kafka-only | none |
+| `pf-lambda-esm-metrics-kafka-metrics-kafka-only` | AWS::Lambda::EventSourceMapping | The KafkaMetrics metric is Kafka-only | none |
+| `pf-lambda-esm-mq-auth-secret-required` | AWS::Lambda::EventSourceMapping | An Amazon MQ event source needs BASIC_AUTH credentials | none |
+| `pf-lambda-esm-mq-cross-account` | AWS::Lambda::EventSourceMapping | The Amazon MQ broker must live in the deploy account | none |
+| `pf-lambda-esm-mq-starting-position-unsupported` | AWS::Lambda::EventSourceMapping | Amazon MQ event sources reject StartingPosition | none |
+| `pf-lambda-esm-msk-topics-required` | AWS::Lambda::EventSourceMapping | A Kafka event source needs Topics | none |
+| `pf-lambda-esm-on-failure-destination-api-max-length` | AWS::Lambda::EventSourceMapping | An on-failure destination ARN is limited to 350 characters | none |
+| `pf-lambda-esm-on-failure-destination-service` | AWS::Lambda::EventSourceMapping | An on-failure destination must be SNS, SQS, S3 or a Kafka topic | none |
+| `pf-lambda-esm-parallelization-factor-stream-only` | AWS::Lambda::EventSourceMapping | ParallelizationFactor only applies to Kinesis and DynamoDB streams | none |
+| `pf-lambda-esm-poller-group-esm-count` | AWS::Lambda::EventSourceMapping | A poller group holds at most 100 event source mappings | none |
+| `pf-lambda-esm-poller-group-name-kafka-only` | AWS::Lambda::EventSourceMapping | PollerGroupName only applies to Kafka sources | none |
+| `pf-lambda-esm-pollers-max-ge-min` | AWS::Lambda::EventSourceMapping | MaximumPollers must be at least MinimumPollers | none |
+| `pf-lambda-esm-provisioned-poller-source-support` | AWS::Lambda::EventSourceMapping | ProvisionedPollerConfig only applies to SQS and Kafka sources | none |
+| `pf-lambda-esm-record-age-effective-min` | AWS::Lambda::EventSourceMapping | MaximumRecordAgeInSeconds starts at 60 seconds | none |
+| `pf-lambda-esm-sasl-scram-512-kafka-only` | AWS::Lambda::EventSourceMapping | SASL_SCRAM_512_AUTH is not accepted on Amazon MQ | none |
+| `pf-lambda-esm-scaling-config-sqs-only` | AWS::Lambda::EventSourceMapping | ScalingConfig only applies to SQS event sources | none |
+| `pf-lambda-esm-scaling-provisioned-mutually-exclusive` | AWS::Lambda::EventSourceMapping | ScalingConfig and ProvisionedPollerConfig are mutually exclusive | none |
+| `pf-lambda-esm-sqs-maximum-pollers-min` | AWS::Lambda::EventSourceMapping | ProvisionedPollerConfig MaximumPollers starts at 2 | none |
+| `pf-lambda-esm-sqs-minimum-pollers-min` | AWS::Lambda::EventSourceMapping | ProvisionedPollerConfig MinimumPollers starts at 2 | none |
+| `pf-lambda-esm-sqs-same-region` | AWS::Lambda::EventSourceMapping | The SQS source queue must sit in the deploy region | none |
 | `pf-lambda-esm-sqs-starting-position` | AWS::Lambda::EventSourceMapping | SQS event sources reject StartingPosition | none |
+| `pf-lambda-esm-starting-position-timestamp-mq-unsupported` | AWS::Lambda::EventSourceMapping | Amazon MQ event sources reject StartingPositionTimestamp | none |
+| `pf-lambda-esm-starting-position-timestamp-requires-at-timestamp` | AWS::Lambda::EventSourceMapping | StartingPositionTimestamp needs StartingPosition AT_TIMESTAMP | none |
+| `pf-lambda-esm-starting-position-timestamp-sqs-unsupported` | AWS::Lambda::EventSourceMapping | SQS event sources reject StartingPositionTimestamp | none |
+| `pf-lambda-esm-tumbling-window-stream-only` | AWS::Lambda::EventSourceMapping | TumblingWindowInSeconds only applies to Kinesis and DynamoDB streams | none |
 | `pf-lambda-memory-max` | AWS::Lambda::Function | MemorySize tops out at 10240 | pending-engine |
 | `pf-lambda-timeout-max` | AWS::Lambda::Function | Timeout tops out at 900 seconds | pending-engine |
 | `pf-logs-filter-pattern-bracket` | AWS::Logs::MetricFilter<br>AWS::Logs::SubscriptionFilter | A filter pattern starting with '[' must end with ']' | none |

package/lib/index.js

@@ -17,7 +17,7 @@ const rules_generated_1 = require("./rules.generated");
  * Preflight.apply(app);
  */
 class Preflight {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "cdk-preflight.Preflight", version: "0.0.50" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "cdk-preflight.Preflight", version: "0.0.52" };
     /**
      * Register the cdk-preflight rules on an App or Stage.
      */