If the notification ends up in the retry queue and the delivery app is restarted the notification will get sent twice.
This is because when the app is restarted another message will be in the retry queue as message available which is a
duplicate of the one in the queue that is a message in flight.
This should complete https://www.pivotaltracker.com/story/show/121844427
personalisation data therefore None check not needed.
If personalisation is None in in db it will get passed through to
template which returns content.
The only update we should be doing to an api key is to expire/revoke the api key.
Removed the update_dict from the the save method.
Added an expire_api_key method that only updates the api key with an expiry date.
We were dropping all tables at the end of the test run, however the alembic_version table is not part of the metadata so was being persisted. Alembic then doesn't upgrade the database next test run, since the version appears up to date, so we were, in the notify_db_session fixture, recreating from MetaData (sqlalchemy models). This involves quite a costly comparison of the postgres system tables and the tables in models.py, which was adding half a second to each test that uses the notify_db_session fixture (virtually all of them).
notifications, when retrieved by notification id, or service id (i.e.
all notifications for service).
There is a new element returned at top level of notification json called
body, which is the template content merged with personalisation. This
is consistent with api to endpoint to create notification which returns
what was sent as 'body' in json response.
Merging of template with personalisation is done in the
NotificationStatusSchema.
Personalisation data in encrypted before storing in db.
10 seconds, 1 minute, 5 minutes, 1 hour and 4 hours.
Total elapsed wait is max 5 hours 6 minutes and 10 seconds.
Changed visibility window of SQS to be 4 hours 10 seconds, longer the max retry period.
Before:
```json
{'data': {'template': '…'}}
```
There’s no need to wrap the response in key because there will only
ever be one valid key for the template preview endpoint.
Flatter is better:
```json
{
'content': '…',
'subject': '…',
'template_type': '…',
…
}
```
The response will be different if there’s an error, but you should be
checking the status code first anyway.
This commit:
- changes the template preview endpoint to return the above format
- adds a test to make sure that the original `/service/…/template/…`
endpoint still returns JSON in the same format (with a `data` key)
