This change does two things:
1. The old `BounceRecord`, `BounceType` and `BounceSubtype` types are
removed from the `auth_db` module into `bounces`, so that they can
more easily be re-used when writing bounce/complaint data to Redis.
2. Those types are renamed to `DeliveryProblem`, `ProblemType` and
`ProblemSubtype` respectively, and the `bounces` module is renamed to
`delivery_problems`. That may seem weird at first, but I have good
reason for it and am open to alternative names if anyone can suggest
something better.
Historically we've always treated complaints as a type of bounce
event, but that's inaccurate because bounces are never preceded by a
delivery event whereas complaints are always preceded by one. This
has caught me out in the past when analysing metrics and expecting a
blanket sum of `deliveries + bounces = sends` to be true. It isn't.
It's only true if you filter complaints from bounces before
calculating the sum.
Because of that, I wanted some different nomenclature that didn't use
"bounces" as an umbrella term for "bounces and complaints". It won't
affect the names we use in the metrics but I think it's important for
language we use in the codebase to be as precise as possible. Things
like "delivery error" or "delivery failure" also seemed inaccurate
for the same reason; a complaint implies that the actual delivery
succeeded. Hence "delivery problems", which seems generic enough to
legitimately include both event types.
Previously, our Redis abstraction only worked with strings because it
only dealt with the somewhat nebulous concept of message metadata. Now
that we also want to use it for concrete types, it makes sense to bake
in automatic serialization from and deserialization to those types. This
frees consumers from the responsibility of having to serialize to a
Redis-friendly format manually.
This change achieves that aim by making the db methods generic. `db.set`
gets a type parameter that is `Serialize` and the getters get one that
is `DeserializeOwned`.
Phil Booth
Beatriz Rizental