audit: nested-key critic blind spots found by the 0809 sweep — mixed-case SDK models, file-global literal heuristic, missing targets, selective sub-key forwards

[go-to-k]

Summary

The 2026-08-09 horizontal sweep of the #1370 class (run with the #1373 critic's own machinery against ALL registered types' live CFn schemas) surfaced bugs the current critic design cannot see. Follow-up work to close the blind spots, complementing #1378 (shape-level v2):

1. Mixed-case SDK models defeat the single per-target keyStyle

NESTED_KEY_TARGETS assumes a whole client is exact (PascalCase) or lower-first (camelCase). But client-eventbridge, client-scheduler, and client-glue are PascalCase models with camelCase ISLANDS (awsvpcConfiguration, capacityProvider, type/field/expression, scanRate/scanAll). An extra classification bucket — "exact-case miss but case-insensitive hit" — is what surfaced the EventBridge/Scheduler Fargate-target create failures and the Glue Crawler drops in the sweep. The critic should flag case-insensitive near-misses REGARDLESS of the target's declared keyStyle (it already has the case-divergence bucket; the gap is that non-target types aren't audited at all and keyStyle hides islands).

2. "Provider names the literal anywhere" heuristic is file-global

The DynamoDB GlobalTable GSI divergence (WriteProvisionedThroughputSettings etc.) was cleared by the literal heuristic because the same key names occur legitimately handled at TOP level elsewhere in the file. Literal evidence should be scoped (per handled top-level property, or at least weighted) — or such known-divergent blobs get explicit allow/deny entries.

3. Extend NESTED_KEY_TARGETS to the remaining blob-forwarding providers

The sweep produced ready-made nested-schema captures for all 133 registered types (fetched via cloudformation:DescribeType). Candidates found to carry real divergences: AWS::Events::Rule, AWS::Scheduler::Schedule, AWS::EMR::Cluster (+ InstanceGroupConfig/InstanceFleetConfig), AWS::Lambda::EventSourceMapping (map-key enum), AWS::CodeBuild::Project, AWS::DynamoDB::GlobalTable, AWS::Glue::Table / ::Crawler, AWS::WAFv2::WebACL, AWS::ECR::Repository, AWS::S3Vectors::VectorBucket (wrong CFn-side spelling — a read-side variant), AWS::Cognito::UserPool. Each has (or will have) its own bug issue; this issue tracks bringing them under the critic so the class stays closed.

4. SDK-bump-dependent unmappable keys (allow-list candidates)

Keys with NO member in the pinned SDK — unmappable until an SDK bump, should be allow-listed with rationale so they surface on every regen instead of silently passing:

• AWS::Cognito::UserPool SmsConfiguration.EumsSms.* (End-User-Messaging SMS block; installed SmsConfigurationType has only SnsCallerArn/ExternalId/SnsRegion)
• AWS::Lambda::Function / ::LayerVersion Code.S3ObjectStorageMode
• AWS::WAFv2::WebACL PreParseTextTransformations, Monetize/PriceMultiplier
• AWS::CodeBuild::Project Environment.HostKernel

5. Selective sub-key forward gaps are invisible to spelling diffs

The Cognito Policies.SignInPolicy drop (same-spelling SDK member exists; the provider just never forwards it) is a class the spelling critic structurally cannot catch — it needs the per-sub-key coverage idea: for a handled blob, every CFn nested key should be either reachable (same-spelling pass-through/spread), explicitly named, or allow-listed. The current critic treats "same spelling exists in SDK" as green even when the provider hand-builds the object and omits the key. Detecting hand-built-object omission likely needs the shape-aware v2 (#1378) machinery.

Related: #1373 (v1 critic), #1378 (shape-level v2), and the individual bug issues from the same sweep.

[go-to-k]

Follow-up from the #1383 / #1384 / #1385 fixes (PRs #1399 / #1398 / #1397) — three concrete inputs for the critic-extension work.

1. New target candidates, with the caveat that two of the three bugs would NOT have been caught.

• AWS::EMR::Cluster / ::InstanceGroupConfig / ::InstanceFleetConfig (AWS::EMR::*: ConfigurationProperties / StepProperties never renamed to SDK Properties — every EMR app configuration silently dropped #1383) — WOULD have been caught: CFn ConfigurationProperties / StepProperties have no same-spelled member in @aws-sdk/client-emr, so the key pass emits no-sdk-member.
• AWS::Lambda::EventSourceMapping (AWS::Lambda::EventSourceMapping: self-managed Kafka Endpoints.KafkaBootstrapServers not translated to SDK enum key — CreateEventSourceMapping fails #1384) — would NOT have been caught. Endpoints is a map keyed by an enum value, not a modeled structure, so there is no KafkaBootstrapServers member to miss; the critic compares model member NAMES. Registering the type is still worth it to fence its seven other forwarded blobs (SelfManagedKafkaEventSourceConfig, DocumentDBEventSourceConfig, ScalingConfig, DestinationConfig, LoggingConfig, MetricsConfig, ProvisionedPollerConfig), but it does not close this bug's class.
• AWS::S3Vectors::VectorBucket (AWS::S3Vectors::VectorBucket: provider reads SSEType/KMSKeyArn but CFn spells SseType/KmsKeyArn — KMS encryption config is dead code #1385) — would NOT have been caught, and this is the mixed-case keyStyle blind spot this issue already lists. CFn spells SseType / KmsKeyArn; the SDK spells sseType / kmsKeyArn. Under keyStyle: lower-first they match cleanly, so the pass classifies them same-spelling and never looks at what spelling the PROVIDER actually reads — which was SSEType / KMSKeyArn, i.e. permanently undefined. The generalisable gap: the critic validates CFn-key -> SDK-member, but never CFn-key -> the literal the provider reads. A "declared handled top-level whose nested keys are read under a spelling absent from the CFn schema" pass would catch it.

2. A shared-helper blind spot the #1383 fix just created.

gen-nested-key-coverage.ts scans a single providerFile for AST string literals as evidence of per-key handling, and does not follow helper imports. PR #1399 extracted the EMR conversion into src/provisioning/emr-configuration.ts, so 'ConfigurationProperties' and 'StepProperties' no longer appear in any of the three EMR provider sources. If EMR is added to NESTED_KEY_TARGETS without teaching the evidence scan to follow same-package helper imports, both keys will flag as false-positive divergences even though they are correctly handled. Same hazard applies to any future provider that factors its conversions out.

3. AWS::ECR::Repository (#1392) is a different class and needs a different pass.

That one is a false handledProperties claim — the property is declared handled but appears on no API call. Neither the key pass nor the shape pass can see it; it needs a "declared-handled top-level whose literal appears in no SDK command input" check.