Modelling and inference rather than platform: supervised methods, features and leakage, metric choice, experimentation and statistics, and defending a result to a stakeholder.
A timeout requests cancellation; it does not stop code. CancelledError is raised at the task next await point, so a task inside blocking code, shielded, in an executor thread, or swallowing the exception keeps running and commits its side effects late. Fix by re-raising CancelledError, keeping blocking calls off the loop, and using asyncio.timeout with a TaskGroup.
Make the write idempotent before you make it correct: partition-level replace rather than append, so rerunning a day produces the same result whether it runs once or five times. Then work out how far the contamination spread, because a downstream table that accumulated rather than recomputed will not fix itself when the source is repaired.
The feature encodes the outcome, so the model reads the answer rather than predicting it. Offline the label and the feature come from the same snapshot, which is why validation looks excellent; in production the feature is empty at scoring time and the signal vanishes. Fix by defining features by when they were available and validating on a forward time split.
Separate the leverage from the merit: the renewal makes the request urgent, it does not make it valuable. Work out the real problem underneath the requested solution, test whether it generalises to other accounts, and price the full cost including permanent maintenance rather than the build estimate. Then choose deliberately between roadmap, configuration, services and no.
A partial index only contains rows matching its predicate, so indexing WHERE deleted_at IS NULL stores five million entries instead of forty million - smaller, shallower, and far likelier to stay cached. The catch is the planner only uses it when it can prove the query predicate implies the index predicate, and it does nothing about dead rows still in the heap.
Treat it as a broken experiment, not a rounding issue. At two million users a 53/47 split is astronomically unlikely by chance, so something removed users non-randomly - and that something almost certainly correlated with the outcome. The result cannot be trusted in either direction, so find the mechanism, fix it and rerun rather than adjusting the numbers.