Pull requests as was would mean that we didn't read from the old queues, so whilst the new code writes to the new "notify" queue, the old code would write to the old plethera of queues. And the readers may not pick it up depending on the order of the deploy.
Safer to leave readers reading from all queues until after the deploy then doing a second deploy to tidy up the config.
can now pass in a query string `?statuses=x,y,z` to filter jobs based on
`Job.job_status`. Not passing in a status or passing in an empty string is
equivalent to selecting every filter type at once.
We want to show developers a log of notifications they’ve sent using the
API in the admin app. In order to indentify a notification it’s probably
helpful to know:
- who the notification was sent to (which we expose)
- when the notification was created (which we expose)
- which key was used to create the notification (which we expose, but
only as the `id` of the key)
Developers don’t see the `id` of the API key in the app anywhere, so
this isn’t useful information. Much more useful is the `type` and `name`
of the key. So this commit changes the schema to also return these.
This commit does some slightly hacky stuff with conftest because it
breaks a lot of other tests if the sample notification has a real API
key or an API key with a non-unique name.
Developers need visibility of what their integration is doing within
the app. This includes notifications sent with a test key.
This commit adds an optional, defaults-to-false parameter to include
notifications sent from a test API key when getting notifications.
Starting arguments on their own line and putting the closing parenthesis
on it’s own line because any subsequent changes to the arguments diff
cleanly (ie without touching any other lines).
- this allows us to send a notification to a provider by means of an API call
- This is in addition to the celery code.
- idea is that we can use this method to help speed up throughput by generating API traffic by node/lambda etc to supplement the celery code in times of high load.
This commit adds the `include_jobs` filter to the
`GET /services/…/notifications` endpoint. It defaults to `True` (ie show
all notifications) but makes it possible to only return notifications
created by _any_ API key.
This is so that we can show a log of all notifications sent through the
API in the admin app.
It does not expose this list to the public `GET /notifications` endpoint
because this would violate our rules about keys only being able to get
notifications created with keys of the same type.
- Thows a NoResultFound sqlalchemy exception
- Which causes a retry. This means we give it a few goes (5, max 5 hours) for the notification to appear.
- Should never happen, only if we get some task overlaps that are unusual that leads to tasks executed in an overlapping nature.
- Driven by the fact we won't know the type in the API call
- hence we need to load notification earlier , so pass it not the id through to the send task to avoid loading it twice.
accepts a page parameter to control what page of data
returns additional pagination fields in the response dict
* page_size: will always be 50. defined by Config.PAGE_SIZE
* total: the total amount of unpaginated records
* links: dict containing optionally prev, next, and last, links to
other relevant pagination pages
also cleaned up some test imports
