mozilla-releng / balrog / #5279

90%

push

circleci

Bug 2013441 - Use orjson to serialize/deserialize objects for the redis cache (#3659)

The main thing here is that Blobs cannot be deserialized from JSON
directly so we have to provide a specific loader to the redis cache,
which is why we weren't using orjson in the first place. The commit is
mostly plumbing to pass the post_load arg through all of the right
cache layers/factories.

I originally thought about making this less invasive and just returning
the value as is from the cache and let the caller decide what to do with
what it got back from the cache (for blobs it could either get a dict or
a Blob object based on whether the cache was hit or not, which could
easily be detected by always calling createBlob on the result and
returning early if it was already a Blob). I went back on this because
it felt more fragile and error prone than doing the conversion
explicitly. It's still no perfect still those cache definitions aren't
tested properly and short of deactivating the LRU cache they're hard to
test locally.

I tested this by disabling the LRU cache completely and using an `assert
cache_value == value_getter()` in the cache hit path then hitting
`/update/3/Firefox/42.0/0/Linux_x86_64-gcc3/en-US/release/None/default/default/update.xml`
on the public API. Everything worked fine.

All the other public caches use trivial objects so we don't need special
loaders for them. The admin app doesn't have redis configured.

I removed test_release_blobs_can_log_after_pickling since it's
irrelevant now but decided against reverting
e8cb2ec09 entirely because getting a
logger once per class instead of once per object still sounds like an
improvement we'd want and the other test to deepcopy is also still
relevant for caches using `make_copies`.

2167 of 2548 branches covered (85.05%)

Branch coverage included in aggregate %.

14 of 15 new or added lines in 1 file covered. (93.33%)

5734 of 6240 relevant lines covered (91.89%)

0.92 hits per line