-
Notifications
You must be signed in to change notification settings - Fork 2
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
chore: fix audit entries and setup Slack notifications for production S3 + Power Automate submissions #3439
Conversation
🤖 Hasura Change Summary compared a subset of table metadata including permissions: Updated Tables (1) |
Removed vultr server and associated DNS entries |
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.
One small question - looks good!
Haven't manually tested so that Kev doesn't get a ping unnecessarily 👍
@@ -125,10 +122,11 @@ const sendToS3 = async (req: Request, res: Response, next: NextFunction) => { | |||
); | |||
}); | |||
|
|||
return res.status(200).send({ | |||
res.status(200).send({ |
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 guess the return
here was the original issue - the audit table step wasn't being properly awaited?
Can't quite follow what the exact issue was but it could be caused by mixing await
and then()
, which can lead to some issues. It might be worth just using async/await throughout and adding back the return
here.
Not sure if this is totally necessary but it might make things a little easier to follow and reason with.
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.
Correct! Everything working as expected without this return
now, sorry I didn't explicitly call this out.
Agree the mix of async/await and an Axios .then()
are a bit confusing to reason about, but this now exactly matches the pattern we have for auditing BOPS etc (perhaps worth revisiting in whole in a future PR for consistency!): https://github.com/theopensystemslab/planx-new/blob/main/api.planx.uk/modules/send/bops/bops.ts#L134
Two key changes here:
s3_applications
audit table following existing pattern so we can keep a basic pulse on production integration activityNotes on testing: