Problem: we were sending the first line of the address in the
`TO_NAME_2` field. This meant that they couldn’t do any PAF lookups with
it, because it wasn’t where they were expecting.
The first line of the address is the second line of what our users give
us. We need to give this to DVLA as the _third_ line of the address
output, which they call `TO_ADDRESS_LINE_1`.
- previously this was unbounded, so it got all jobs older then 7 days. In excess of 75,000 🔥
- this meant that the job took (a) a long time and (b) a lot memory and (c) doing the same thing every day
These changes mean that the job has a 2 day eligible window for jobs, minimising the number of eligible jobs in a run, whilst still retaining some leeway in event if it failing one night.
In principle the job runs early morning on a given day. The previous 7 days are left along, and then the previous 2 days worth of files are deleted:
so:
runs on
31st
30,29,28,27,26,25,24 are ignored
23,22 jobs here have files deleted
21 and earlier are ignored.
- This is a CONNECT and a READ timeout.
- Gets wrapped in the standard client exception, with a status code of 504, message Gateway timeout.
- Is quiet noisy in logs to allow us to see it
- Ensures we flick across the provider.
To test change the timeout to 0 and it will timeout.
Brings in:
- [ ] https://github.com/alphagov/notifications-utils/pull/135
Also adds extra tests for:
- the exact issue that we saw in production when #867 was deployed
- what happens when `None` is passed as a placeholder value, because
this should never get as far as the relevant bit of utils
If the date range is with the last 7 days we query Notifcations.
If the date range is outside of the last 7 days we query NotificationHistory.
NotificationHistory does not persist notifications created with a test api key.
1) Beat worker now a single instance with 128M memory
2) New worker for periodic tasks. Single worker, 2G ram
3) new worker for priority queues. Standard instance and memory settings.
We are now spinning this periodic worker off into it's own worker, so it's not bundled with the app. this means we can set it's memory usage specifically so we don't need to bump all the workers.
Whatever a user has entered for their service’s contact block should
appear in the right place in the file we give to DVLA.
The work to output in the right fields in the DVLA file has already been
done. We just weren’t passing it through. This commit passes it through.
Extends the test to make sure that the thing that builds each line of
the file is getting called with the right template, personalisation and
numeric ID. Will be helpful the more complicated the call to the
template gets.
Rather than generating each digit of the number, generate the whole
random number in one go. Should be faster, and is a bit easier to read.
Don’t need to worry about it not being zero-padded because the
`Template` class handles this here:
6ddd2ff352/notifications_utils/template.py (L410)
Using `+` to concatenate strings isn’t very memory efficient. Not sure
if there are real-world implications for how it’s being used here, but
can’t hurt to use `.join` instead.
Rewriting it as a generator also lets us remove some unneeded variable
assignment.
Before the longer tasks all ran on the hour, at midnight, 1 and 2.
Now we run one at midnight, one at quarter past, half past then at quarter too. Trying to spread the load.
