Skip to content

Conversation

svidgen
Copy link
Member

@svidgen svidgen commented Sep 16, 2025

Description of changes

  1. Instructions for Q to help with coding, testing, investigating test/e2e failures
  2. Q assisted upgrade aws-sdk v2 -> v3, starting with ddb utils
CDK / CloudFormation Parameters Changed

Issue #, if available

Description of how you validated changes

Checklist

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

svidgen added 11 commits August 20, 2025 09:45
- Migrate ssmClient.ts from aws-sdk v2 to @aws-sdk/client-ssm v3
- Update all method calls to use command pattern instead of .promise()
- Update error handling to use exception names instead of error codes
- Update package.json to add @aws-sdk/client-ssm dependency
- Remove aws-sdk v2 dependency from amplify-category-api package
- Update test file to use v3 SDK mocking patterns
- All tests passing, build successful

This completes the amplify-category-api migration to AWS SDK v3.
AWS AppSync service changed error message format from
'GraphQL API {id} not found.' to 'API not found'.
This is not related to SSM migration but due to AWS service behavior change.
Updated test expectation to match current service response.
- Update amplify-util-mock DynamoDB utilities to use @aws-sdk/client-dynamodb
- Replace aws-sdk-mock with aws-sdk-client-mock for testing
- Fix type definitions to use proper SDK v3 enums (KeyType, ScalarAttributeType)
- Update test patterns and mock assertions for SDK v3 compatibility
- All DynamoDB tests passing with 86%+ coverage
- Fix TypeScript import syntax in DynamoDB test files
- Add comprehensive e2e testing workflow to AmazonQ.md
- Update dependency licenses and yarn.lock files
- Replace SDK v2 client from dynamodb-simulator with proper SDK v3 DynamoDBClient
- Fix client config access for SDK v3 compatibility
- Store emulator URL on client for datasource configuration
- Resolves mock_e2e_tests failures in CI
- Add yarn e2e-list to enumerate recent build batches
- Add yarn e2e-failed to show failed builds with log commands
- Add yarn e2e-logs to fetch build logs for specific builds
- Update documentation with new commands
- Provides low-context mechanism for Q to query e2e test results
- Display source branch for each build batch
- Helps identify relevant batches for current working context
- Branch shown alongside timestamp for better context matching
- Change default from 10 to 20 most recent batches
- Update help text and documentation
- Provides better coverage of recent test activity
- Add optional filter parameter to distinguish e2e vs canary runs
- E2E runs: contain 'e2e-workflow' in batch ID
- Canary runs: contain 'canary-workflow' in batch ID
- Usage: yarn e2e-list [limit] [e2e|canary]
- Helps focus on relevant test types for troubleshooting
@svidgen svidgen marked this pull request as ready for review September 24, 2025 14:03
@svidgen svidgen changed the title [WIP] chore: aws sdk v3 amplify category api chore: aws sdk v3 amplify category api Sep 24, 2025
@svidgen svidgen changed the title chore: aws sdk v3 amplify category api chore: upgrade aws-sdk to 3 for ddb util mock Sep 24, 2025
Copy link
Contributor

@ShadowCat567 ShadowCat567 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general this looks good, especially since most of this is just find and replace.

"amplify-function-plugin-interface": "^1.9.7",
"amplify-nodejs-function-runtime-provider": "^2.5.23",
"aws-appsync": "^4.1.9",
"aws-sdk": "^2.1113.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are this (aws-sdk) and aws-sdk-mock able to be removed as dependencies now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oversight ... probably means Q and I missed a few things. Working on it.

await waitTillTableStateIsActivePromise;
expect(describeTableMock.mock.calls[0][0]).toEqual({ TableName: 'table1' });

expect(ddbMock.commandCalls(DescribeTableCommand)[0].args[0].input).toEqual({ TableName: 'table1' });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should be able to use some stuff from this package aws-sdk-client-mock-jest, which is a part of the aws-sdk-client-mock package to make this look cleaner (https://github.com/m-radzikowski/aws-sdk-client-mock?tab=readme-ov-file#custom-matchers)


const calls = ddbMock.commandCalls(DescribeTableCommand);
expect(calls.length).toBe(4);
expect(calls[0].args[0].input).toEqual({ TableName: 'table1' });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similar idea where this can look cleaner/be easier to understand with aws-sdk-client-mock-jest (in this case:
EX: expect(ddbMock.commandCalls(DescribeTableCommand)).toHaveLength(4); expect(ddbMock).toHaveReceivedNthCommandWith(1, DescribeTableCommand, { TableName: 'table1' });
...
expect(ddbMock).toHaveReceivedNthCommandWith(4, DescribeTableCommand, { TableName: 'table1' });)
This and the previous comment related to this are not really blocking, more ways of rewriting this that makes it a bit easier to tell what we are expecting to see with this test

{
AttributeName: 'createdAt',
KeyType: 'SORT',
KeyType: 'RANGE',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why was this changed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is v3 being more strict on KeyType. The correct values for this field are HASH or RANGE, as far as I can tell.

@@ -0,0 +1,402 @@
#!/usr/bin/env ts-node
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this file (scripts/e2e-test-manager) and quick-build-status.sh be removed from this PR? It looks like they are artifacts from Q

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of keeping these scripts around. Should be useful in general.

@@ -0,0 +1,47 @@
# Q Workspace
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to keep this .q folder in the PR?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I'm of two minds on this. I'll let this question simmer while I dig more on some of the other oddities.

const client: DynamoDB = await dynamoEmulator.getClient(emulator);

// Create SDK v3 client instead of using the v2 client from getClient
const client = new DynamoDBClient({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any particular reason why we are creating the DynamoDB Client here instead of updating the dynamoEmulator to use aws-sdk v3?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure yet. I need to dig on this a little myself.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah, I think I let this one slide to limit scope. Keep Q updates restricted to per-package updates -- but, taking a peek at getClient(), it looks like it should be fairly isolated. I'll make that change as long as there's no significant collateral damage.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. There will either be some sprawl or a very light temporary compatibility layer if we tug on this in this PR. Would prefer to keep this as-is in the PR.


if (client) {
await createAndUpdateTable(client, config);
config = configureDDBDataSource(config, client.config);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are we unable to extract the config from the aws sdk v3 client?

…rtions

- Replace manual commandCalls() checks with toHaveReceivedCommand* matchers
- Add aws-sdk-client-mock-jest import to test files
- Improve test readability and maintainability
- All tests continue to pass with cleaner assertions
- Update getClient() in amplify-dynamodb-simulator to use DynamoDBClient
- Add backward compatibility layer to maintain v2-style API (.promise() methods)
- Strip v3 metadata from responses to match v2 response format
- Update e2e utils to use dynamoEmulator.getClient() instead of direct creation
- Add @aws-sdk/client-dynamodb dependency to amplify-dynamodb-simulator
- All tests passing with v3 client under the hood
- Remove aws-sdk and aws-sdk-mock from package.json
- Update e2e test to remove AWS SDK v2 credential clearing
- Fix KeyType from 'SORT' to 'RANGE' in util.test.ts for SDK v3 compatibility
- All tests passing with AWS SDK v3 migration complete
- Update dependency_licenses.txt to reflect removed AWS SDK v2 packages
- Update yarn.lock to remove unused dependencies from aws-sdk-mock and aws-sdk v2
- Fixes e2e test failures for verify_yarn_lock and verify_dependency_licenses_extract
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants