-
Notifications
You must be signed in to change notification settings - Fork 86
chore: upgrade aws-sdk to 3 for ddb util mock #3337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: release-api-plugin-stable
Are you sure you want to change the base?
chore: upgrade aws-sdk to 3 for ddb util mock #3337
Conversation
- 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.
This reverts commit 3de734d.
- 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
…wirej/aws-sdk-v3-amplify-category-api
There was a problem hiding this 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", |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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' }); |
There was a problem hiding this comment.
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' }); |
There was a problem hiding this comment.
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', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why was this changed?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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({ |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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
This reverts commit 80a4b7a.
- 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
Description of changes
aws-sdk
v2 -> v3, starting with ddb utilsCDK / CloudFormation Parameters Changed
Issue #, if available
Description of how you validated changes
Checklist
yarn test
passes/batch/amplify-category-api-e2e-workflow:ff165713-ece3-4038-8546-3a08020433fe?region=us-east-1)
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.