The new release of flake8-bugbear is starting to flag positional argument unpacking that comes after keyword arguments in function calls as a style warning that fails. This is a good thing to catch because it can lead to unexpected side effects with function arguments and/or errors thrown by Python.
See the following links for more details:
- https://stackoverflow.com/questions/58961715/python-value-unpacking-order-in-method-parameters
- https://github.com/python/cpython/issues/82741
This changeset fixes a couple of instances where the positional argument unpacking was happening after keyword arguments were being provided.
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
This stat is shown on a few of our pages, such as our homepage,
the performance page and also a platform admin page
and is currently catched for the
default TTL of 1 week. I think there is no reason we can't make
this only cache once an hour and give slightly more up to date stats
which will update more regularly.
This mimics the approach and also the TTL choice of 1 hour that has
been added for the performance page (although there is no
particular bug here to fix, it is just nice to have slightly more up
up to date data).
Note, the API call only takes about 0.3 seconds at the moment
so it is not particularly intensive on the DB to run this more
regularly.
Returns the data calculated by the API. Stored in Redis against a
hardcoded key so that no-one hammering the home page is directly hitting
the database.
This removes some code which is duplicative and obscure (ie it’s not
very clear why we do `"a" * 73` even though there is a Very Good Reason
for doing so).
Currently requests to the API made from the admin app are going from
PaaS admin app to the nginx router ELB, which then routes them back
to the api app on PaaS.
This makes sense for external requests, but for requests made from
the admin app we could skip nginx and go directly to the api PaaS
host, which should reduce load on the nginx instances and
potentially reduce latency of the api requests.
API apps on PaaS are checking the X-Custom-Forwarder header (which
is set by nginx on proxy_pass requests) to only allow requests going
through the proxy.
This adds the custom header to the API client requests, so that they
can pass that header check without going through nginx.
Because we’re setting the API key and service ID after calling the
`__init__` method of the client it wasn’t doing the thing where it
splits the combined key into the two individual UUIDs. So we still need
to set them directly, individually on the client.
The Notify API client changed in version 4 to take two arguments, not
three (service ID was removed in favour of the combined API key).
This gets a bit gnarly because the API key has to be at least a certain
length so it can be substringed internally.
The clients never get passed useful values to their `__init__` methods.
Rather the real values are passed through later using the `init_app`
method.
So it should be an error if the client is relying on the values that
get passed to it’s init method. Easiest way to ensure this is by making
the `__init__` method not expect any arguments and passing fake values
to the `Super` call.
