Pamela is keen to make a version of this email alert available to people in the newsroom outside of her team, but for this new version she would like the numbers to match what is on the government dashboard.
The government dashboard states:
"Data shown are cases by specimen date and because these are incomplete for the most recent dates, the period represented is the 7 days ending 5 days before the date when the website was last updated."
This time window lags the time window for the email we have been sending until now, which represents the 7 days ending the last day for which the API returns data. We still think there is value in sending alerts based on the most up-to-date but possibly incomplete data, but since the caveat is difficult to understand we do not want to send these alerts to people who aren't in the know.
As such, here we modify the stack to have two lambdas, one which triggers an email with the "verified" data which matches the dashboard, and one which triggers an email with the most up-to-date but "unverified" data.
How to test
Testing the code
For the verified email type, working out exactly how many days to subtract from the latest date for which we see data at the time of running was a little fiddly, but we have settled on 4 days since:
our lambda runs at 8am
the government data is updated at 4pm
running locally before 4pm (e.g. at 10am today), we see:
this matches the numbers on the dashboard:
For the unverified email type, running locally setting the environment variable EMAIL_TYPE=UNVERIFIED and artificially lowering the PERCENTAGE_CHANGE_THRESHOLD to 50.0, we see results up to two days ago:
Testing the infrastructure
I have fully deployed the lates build for this branch and run the lambdas to receive emails
What does this change?
Pamela is keen to make a version of this email alert available to people in the newsroom outside of her team, but for this new version she would like the numbers to match what is on the government dashboard.
The government dashboard states: "Data shown are cases by specimen date and because these are incomplete for the most recent dates, the period represented is the 7 days ending 5 days before the date when the website was last updated."
This time window lags the time window for the email we have been sending until now, which represents the 7 days ending the last day for which the API returns data. We still think there is value in sending alerts based on the most up-to-date but possibly incomplete data, but since the caveat is difficult to understand we do not want to send these alerts to people who aren't in the know.
As such, here we modify the stack to have two lambdas, one which triggers an email with the "verified" data which matches the dashboard, and one which triggers an email with the most up-to-date but "unverified" data.
How to test
Testing the code
For the verified email type, working out exactly how many days to subtract from the latest date for which we see data at the time of running was a little fiddly, but we have settled on 4 days since:
For the unverified email type, running locally setting the environment variable
EMAIL_TYPE=UNVERIFIEDand artificially lowering thePERCENTAGE_CHANGE_THRESHOLDto50.0, we see results up to two days ago:Testing the infrastructure
I have fully deployed the lates build for this branch and run the lambdas to receive emails