fix(glue): rename the Crawler DynamoDB scan members and the Iceberg table input to their SDK spellings

[go-to-k]

Summary

Two GlueProvider sites forwarded a CFn blob raw where the SDK model diverges. The AWS SDK v3 serializer drops unknown members, so the values silently never reached AWS while the call reported success.

Issue	CFn key	SDK member	Effect
#1391	Targets.DynamoDBTargets[].ScanAll / .ScanRate	scanAll / scanRate	scan tuning lost; the target itself survived (matched by Path)
#1390	OpenTableFormatInput.IcebergInput.IcebergTableInput	IcebergInput.CreateIcebergTableInput	the entire Iceberg table spec (Location / Schema / PartitionSpec / WriteOrder / Properties) discarded

What changed

• Crawler. The SDK's DynamoDBTarget is a lowercase island in an otherwise-PascalCase model — Path is PascalCase but the scan-tuning members are not. Converted on create and update, with the inverse applied in readCurrentState so drift no longer reports a phantom ScanRate removal plus scanRate addition. The other seven CrawlerTargets sub-types were audited against the SDK model and match CFn key-for-key (MongoDBTarget.ScanAll genuinely IS PascalCase) — recorded in a comment so the audit is not repeated.

• Table. A single key rename; the renamed object's own members match CFn 1:1. The stale "maps 1:1 to the SDK type (same PascalCase)" comment is corrected, as is the vague UpdateTable claim beside it: UpdateTableRequest has no OpenTableFormatInput member at all — it carries the different, update-only UpdateOpenTableFormatInput shape that CFn does not model.

• Retry patterns (2 new). Adding a DynamoDB crawler target makes CreateCrawler eagerly call dynamodb:DescribeTable as the crawler role, which turns the fixture into a sensitive probe of IAM propagation. It surfaced two AWS wordings of that race that cdkd did not retry, each failing the deploy outright:

  • Service is unable to assume the role <arn> to access null. Please verify the role's TrustPolicy. — the existing entry is anchored on is unable to assume provided role, which does not match the role <arn>.
  • The security token included in the request is invalid. (Service: AmazonDynamoDBv2; ... UnrecognizedClientException) — Glue assumed the fresh role and the resulting session's token was not valid yet. This one became deterministic once the crawler was correctly ordered after the role and its policy, and adding the pattern is what turned a reproducible failure into a clean pass.

  The second pattern is anchored on the Java-SDK (Service: trailer, which is load-bearing: that trailer appears only on a SERVICE-wrapped error, so the developer's own expired SSO session (same sentence, JS SDK, no trailer) still fails fast instead of burning ~48s of retries. A dedicated negative test pins that.

• Numeric + boolean coercion. toSdkCrawlerTargets is now the wire boundary for Targets, and CFn is stringly typed, so ScanRate: "0.9" was being forwarded verbatim to a double member. Both members are coerced per the repo convention — ScanAll: "false" matters more, since the raw string is TRUTHY and would silently invert the setting. Unparseable input passes through so AWS surfaces the real validation error.

Test plan

• 12 new unit tests. 8 are genuinely red against the pre-fix provider (both renames on create + update, the readCurrentState inverse, the ScanRate coercion, and both new retry patterns); the rest are over-conversion / pass-through guards that are green either way by construction, plus the expired-credentials negative guard.

• Full suite: 516 files / 8723 tests, no type errors.

• Real AWS, AWS::Glue::Crawler: DynamoDBTargets[].ScanRate/ScanAll dropped (SDK members are lowercase scanRate/scanAll) #1391 (/run-integ glue-update-hardening, us-east-1). The fixture now carries a DynamoDB crawler target with deliberately NON-default scan tuning — AWS defaults ScanAll to true and stores ScanRate as null when unset, so a default echo cannot satisfy the assertion. GetCrawler confirmed scanAll=false scanRate=0.9 after create and scanAll=true scanRate=1.2 after the UPDATE phase. Clean destroy, 0 orphans.

• Real AWS, AWS::Glue::Table: IcebergInput.IcebergTableInput never renamed to SDK CreateIcebergTableInput — Iceberg table spec silently dropped #1390 — proven by A/B rather than by a green fixture. Both directions were exercised against a live IcebergSpecTable:

  • pre-fix (rename reverted): the table creates successfully and its location comes from TableInput.StorageDescriptor only — the Iceberg spec silently discarded, i.e. the reported bug reproduced;
  • post-fix: Glue rejects with Table metadata information present at multiple parts of input request, an error only reachable if the renamed key did arrive.

  That is a stronger signal than a passing assertion, but it is not a green fixture, so the fixture change was reverted rather than shipped half-working. Details and the three rejected request shapes are in (test(integ): no real-AWS coverage for AWS::Glue::Table IcebergTableInput — the correct CreateIcebergTableInput request shape is undocumented #1408).

Known gaps (reviewer-surfaced, deliberately not widened into this PR)

• AWS::Glue::Crawler / ::Table are not in NESTED_KEY_TARGETS. Both bugs are textbook case-divergence / no-sdk-member hits for the nested-key critic, so unit tests are the only mechanical guard here. Adding them needs a CFn-schema fixture re-capture (nestedProperties / definitionShapes), which is the critic-target expansion tracked in (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 #1393).
• Stringly-typed drift. A hand-written ScanRate: "0.9" is now coerced on the wire, but state still records the string while readCurrentState returns the number — a phantom-drift class that pre-dates this PR and affects the provider generally.
• The update phase's scanAll: true matches AWS's own default, so scanRate: 1.2 is what carries the regression signal for that phase. Noted in a comment at the assertion; the create phase asserts the drop-proof false / 0.9 pair and fails first regardless.

Follow-ups

• No real-AWS coverage for IcebergTableInput (test(integ): no real-AWS coverage for AWS::Glue::Table IcebergTableInput — the correct CreateIcebergTableInput request shape is undocumented #1408): the request shape Glue accepts is undocumented — the published IcebergInput doc page is stale, and the CFn spec marks Location / Schema required in a way AWS's own validation contradicts. Same shape of gap as (test(integ): no real-AWS coverage for any EMR InstanceTypeConfigs path (instance-fleet nested Configurations) #1400) for EMR instance fleets.
• The AWS::Glue::* types are not in NESTED_KEY_TARGETS, so the nested-key critic would not have caught either divergence. That target expansion is tracked in (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 #1393).

Closes #1391
Closes #1390

[github-actions]

🎉 This PR is included in version 0.278.8 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀