Add upsert lambda #280
Add upsert lambda #280
Conversation
francisco-videira-nhs
force-pushed
the
feature/CCM-12997
branch
from
8c4f7c3 to
8a74c03
Compare
infrastructure/terraform/components/api/module_lambda_upsert_letter.tf
Outdated
Show resolved
Hide resolved
| }; | ||
|
|
||
| function createDocumentClient(): DynamoDBDocumentClient { | ||
| const ddbClient = new DynamoDBClient({}); |
There was a problem hiding this comment.
should the region be passed in during creation?
Which region is used by default if you omit it?
There was a problem hiding this comment.
From https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/setting-region.html :
- "The SDK for JavaScript doesn't select a Region by default. However, you can set the AWS Region using an environment variable, or a shared configuration config file."
- "Order of precedence for setting the Region": passed to constructor -> env var -> shared config file
From what I can tell, the Lambda service itself injects env vars depending on where it is deployed, and then the SDK will pick it up. We could be clearer and have fallbacks though when creating the clients, I think we need a tech debt for this because other Lambdas in the project are creating the clients like this as well
masl2
dismissed stale reviews from Vlasis-Perdikidis and m-houston
via
547f6b1
* swap partition and sort for letters * store changes and source, subject, billingref * unsafe marker * rename correctly
| test("processes all v1 records successfully and returns no batch failures", async () => { | ||
| const evt: SQSEvent = { | ||
| Records: [ | ||
| createSqsRecord( | ||
| "msg1", | ||
| JSON.stringify(createNotification(createPreparedV1Event())), | ||
| ), | ||
| createSqsRecord( | ||
| "msg2", | ||
| JSON.stringify( | ||
| createNotification( | ||
| createPreparedV1Event({ | ||
| id: "7b9a03ca-342a-4150-b56b-989109c45614", | ||
| domainId: "letter2", | ||
| url: "s3://letterDataBucket/letter2.pdf", | ||
| }), | ||
| ), | ||
| ), | ||
| ), | ||
| ], | ||
| }; |
There was a problem hiding this comment.
A parameterised test structure might be worth considering - maybe as a tech debt - as for each path (insert or upsert) I expect regardless of the supported event input we would want the same outputs.
Although it would still require extra tests for mixed events etc, I wonder if it might be easier to maintain/reduce the boilerplate?
There was a problem hiding this comment.
Tried to reduce the boilerplate. Yeah there can be a mix of input/outcome... With parameterised maybe we'd lose what the test is doing if we lose the descriptions? Can raise a tech debt though
|
|
||
| await Promise.all(tasks); | ||
|
|
||
| return { batchItemFailures }; |
There was a problem hiding this comment.
Does batch failure support not require a terraform configuration to be set on the queue?
There was a problem hiding this comment.
It is yup, it's currently set in
5 participants
Description
Context
Type of changes
Checklist
Sensitive Information Declaration
To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.