fix(graphql-model-transformer): derive imported DynamoDB table key schema from @primaryKey

[sharonyajain]

Problem

When migrating a Gen 1 backend to Gen 2 with migratedAmplifyGen1DynamoDbTableMappings, any model whose schema declares a custom @primaryKey (partition key other than id) fails deployment. The Custom::ImportedAmplifyDynamoDBTable resource is synthesized with an expected key schema of id/HASH, so the TableManager import validation rejects the (correct) live Gen 1 table:

Received response status [FAILED] from custom resource. Message returned:
Imported table properties did not match the expected table properties.

The branch stack then rolls back (ROLLBACK_COMPLETE); because it is a failed CREATE, the stack must be deleted manually before any retry.

Reported in #3489 (surfaced downstream as aws-amplify/amplify-backend#3281).

Why it matters

This blocks Gen 1 → Gen 2 migration for any customer whose data model uses a custom primary key — a common pattern — mid-migration, with a rough manual-cleanup recovery. In a reported 19-model schema, 18 tables (default id keys, several with GSIs) migrated fine; the single model with a custom @primaryKey was the only failure.

Fix (symptom → root cause → change)

• Symptom: the imported table's expected keySchema/attributeDefinitions are id/HASH regardless of the model's @primaryKey.
• Root cause: AmplifyDynamoModelResourceGenerator.createModelTable instantiates AmplifyDynamoDBTable with a hardcoded partitionKey: { name: 'id', type: STRING } for every table, including imported ones. For owned tables the @primaryKey transformer (replaceDdbPrimaryKey in the index transformer) corrects the key schema downstream via cfnTable.addPropertyOverride(...). That correction does not reach the imported-table validation path, which consumes the initial construct properties directly (import-table.ts → getExpectedKeySchema returns createTableInput.KeySchema verbatim). GSIs are unaffected because they are already derived from the model.
• Change: in createModelTable, for imported tables only, derive the partition key — and the sort key (single or composite) — from the model's @primaryKey via getPrimaryKeyFieldNodes, mirroring how GSIs are already derived from the model. Composite sort keys reuse the same ModelCompositeKeySeparator() join as the transformer's getSortKeyName. Owned tables are untouched (still id, corrected downstream exactly as before).

Tests

Added three regression tests in amplify-dynamodb-table-generator.test.ts, each asserting the synthesized Custom::ImportedAmplifyDynamoDBTable properties:

• custom @primaryKey (partition key ≠ id) → keySchema/attributeDefinitions use userAuthenticating, not id.
• custom @primaryKey with a sort key → keySchema is [HASH, RANGE] on the model fields (this case caught a gap in the first iteration and drove the sort-key handling).
• imported table without a custom @primaryKey → still id/HASH (no regression).

Verified these tests fail on the base code (imported table synthesizes id/HASH) and pass with the fix — confirmed reproduction, not just static analysis.

Manual verification

• amplify-dynamodb-table-generator.test.ts: 7/7 pass.
• Full @aws-amplify/graphql-model-transformer suite: 12 suites / 203 tests / 87 snapshots pass — no snapshot drift (the change is gated on isTableImported).
• @aws-amplify/graphql-index-transformer suite: 93 tests pass.
• tsc --noEmit on graphql-model-transformer: clean.

Screenshots

N/A — no user-visible UI change (GraphQL transformer synthesis only).

[soberm]

Reviewed the fix for deriving imported DynamoDB table key schema from @primaryKey. The core fix is correct and safely scoped to the imported-table path — no blocking issues. Leaving a few suggestions (test coverage for composite/numeric/enum keys) and nitpicks (DRY/typing).

[sharonyajain]

Addressed the latest review batch in 2b27d4201. Dispositions:

Applied

• Extracted the key derivation into a private getImportedTableKeySchema method plus a keyAttributeType helper; createModelTable is now a single call. No behavior change.
• Added derives the implicit id key schema for an imported table whose model declares no id field (a type Note @model { content: String } with no id and no @primaryKey), covering the getImplicitlyDefinedIdField fallback. File now has 11 tests; full graphql-model-transformer suite is 207 tests / 87 snapshots green, tsc clean.