Feature/replace notifications node client package

[craigzour]

Summary | Résumé

The objective with this change is to have errors where we can actually see why GC Notify are rejecting our requests.

• Replaces notifications-node-client package with our own custom GCNotifyClient tiny lib

Example:

• When a form submission is too large and has to be sent through GC Notify, our reliability queue would fail and give us an error.

Before

2024-08-16T18:25:22.541Z 5ec404c6-40c3-4e6b-a678-981fefddd959 ERROR {"level":"error","severity":2,"submissionId":"cfaeef05-b499-419c-9bbc-468518ef3e92","sendReceipt":"53868627-8397-4e68-a042-805de4600410","msg":"Failed to send submission through GC Notify","error":"Request failed with status code 400."}

(and)

2024-08-16T18:25:22.543Z 5ec404c6-40c3-4e6b-a678-981fefddd959 INFO {"message":"Request failed with status code 400","name":"Error","stack":"Error: Request failed with status code 400\n at createError (/var/task/node_modules/notifications-node-client/node_modules/axios/lib/core/createError.js:16:15)\n at settle (/var/task/node_modules/notifications-node-client/node_modules/axios/lib/core/settle.js:17:12)\n at IncomingMessage.handleStreamEnd (/var/task/node_modules/notifications-node-client/node_modules/axios/lib/adapters/http.js:312:11)\n at IncomingMessage.emit (node:events:529:35)\n at endReadableNT (node:internal/streams/readable:1400:12)\n at process.processTicksAndRejections (node:internal/process/task_queues:82:21)","config":{"transitional":{"silentJSONParsing":true,"forcedJSONParsing":true,"clarifyTimeoutError":false},"transformRequest":[null],"transformResponse":[null],"timeout":0,"xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN","maxContentLength":-1,"maxBodyLength":-1,"headers":{"Accept":"application/json, text/plain, */*","Content-Type":"application/json","Authorization":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiIzNWU3ZjM1OC0yNjgzLTQ0YjktODAyNy1jOTg0ZTFkMDE4ZDgiLCJpYXQiOjE3MjM4MzI3MjJ9.CzT4HgZzA0xOzU-_ifLgBYUDoX-7_nVLRScQTfKN-gY","User-Agent":"NOTIFY-API-NODE-CLIENT/5.2.3","Content-Length":250385},"method":"post","url":"https://api.notification.canada.ca/v2/notifications/email","data":"{\"template_id\":\"8d597a1b-a1d6-4e3c-8421-042a2b4158b7\",\"email_address\":\"[email protected]\",\"personalisation\":{\"subject\":\"test - Response\",\"formResponse\":\"[[en]]\\n# test -

After

2024-08-16T18:19:36.746Z 04ed99fc-d4b3-43af-a52d-956fe658b670 ERROR {"level":"error","severity":2,"submissionId":"e6e3b2d0-249e-4b4a-b4f5-90769cfa724f","sendReceipt":"b23c637c-85b4-4cdd-8bd8-de212ab01205","msg":"Failed to send submission through GC Notify","error":"Failed to send submission through GC Notify to [email protected]. Reason: GC Notify errored with status code 400 and returned the following detailed errors [{\"error\":\"ValidationError\",\"message\":\"Personalisation variables size of 250171 bytes is greater than allowed limit of 220000 bytes.\"}].."}

In the new error message we can actually see that the problem is that the personalisation payload is too large.

Note

I tried different approaches for sharing the GCNotifyClient code between the 3 lambda functions that use it.

The two most elegant ones were:

• Create an internal npm package that can be added as a dependency to our lambda functions
• Have a lib folder in the lambda-code folder with the gc-notify-client.ts file in it and then use a symbolic link in every lambda function so that we can change it in just one place

Unfortunately there was always something that would prevent me from finalizing the implementation. Some are definitely doable but would require important refactoring. The main issues are always around the containerization process.

As this is not something we want to spend a lot of time on for now I decided to go with the CopyPasta solution!