feat: Only send status checks when payload has changed

[scott-codecov]

Resolves codecov/engineering-team#350

Only send status notifications when the payload has changed from the last time we sent the same notification.

[codecov]

Codecov Report

Merging #74 (348d638) into main (aca010e) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #74   +/-   ##
=======================================
  Coverage   98.59%   98.59%           
=======================================
  Files         359      359           
  Lines       26284    26322   +38     
=======================================
+ Hits        25914    25952   +38     
  Misses        370      370           

Flag	Coverage Δ
integration	98.56% <100.00%> (+<0.01%)	⬆️
latest-uploader-overall	98.56% <100.00%> (+<0.01%)	⬆️
onlysomelabels	98.59% <100.00%> (+<0.01%)	⬆️
unit	98.56% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
NonTestCode	97.30% <100.00%> (+<0.01%)	⬆️
OutsideTasks	98.34% <100.00%> (+<0.01%)	⬆️

Files Changed	Coverage Δ
services/notification/notifiers/status/base.py	98.67% <100.00%> (+0.10%)	⬆️
...s/notification/notifiers/tests/unit/test_status.py	100.00% <100.00%> (ø)

Related Entrypoints
run/app.tasks.notify.Notify

[giovanni-guidini]

looks good, left a comment about the cache key tho

[giovanni-guidini]

if the payload is JSON serializable (not sure if it is), can we use the payload as the key?
It would save us the last_payload != payload check... if the payload is there (as a key) we know we sent that before (in the last TTL seconds)

[scott-codecov]

I'm not sure that would work as expected. Imagine the following sequence of events...

1. notify with payload X -> hashes to ABC (not in cache so we send notification)
2. notify with payload X -> hashes to ABC (already cached, skip notification)
3. notify with payload Y -> hashes to DEF (not in cache so we send notification)
4. notify with payload X -> hashes to ABC (already in cache, skip notification)

We need to make sure that the last item there actually DOES send a notification.

[giovanni-guidini]

ah I see... Then indeed my understanding was incorrect.
I thought that case 4 there would indicate a task that got delayed for whatever reason (had to retry for example) and was "stale" data (because something more recent, in this case payload Y) was already delivered.

But indeed I see that case 4 would skip notification and it's not what we want.
Thanks for taking the time to explain.