Reporting data catches up: the metrics backlog that was leaving dashboards stale has been cleared, and the pipeline no longer rebuilds the same numbers twice
Dashboards stop lagging behind your ad accounts
- If your reporting numbers have been arriving late — a dashboard still showing yesterday's figures long after the platform had today's — this is the fix. The pipeline that adopts new ad-account data into our reporting tables had built up a backlog of overdue work, and that backlog is what you were seeing as staleness. It now drains through the reconciler instead of accumulating.
- The root cause was two separate problems compounding. Multiple identical refresh requests for the same underlying data were each doing the full rebuild independently, so the system spent its capacity recomputing numbers it had already computed. Those duplicate refreshes now coalesce: one physical refresh serves every request for the same exact data, and the rest wait for it rather than racing it.
- The second problem was database deadlocks. Different parts of the pipeline were taking the same set of locks in different orders — the planners, provider callbacks, settlement and reconcile, account deletion, and grant revocation each had their own sequence — which meant that under load they would periodically block each other and a batch of reporting work would die. All of those paths now acquire locks in one canonical order, so the compositions that used to deadlock simply do not any more.
Interrupted refreshes now recover instead of stalling
- Each unit of reporting work now records durable ownership of its own attempt. Previously, if the worker processing a refresh disappeared mid-flight — a deploy, a node eviction, a crash — the work could be left in a state where nothing picked it back up, and that row stayed overdue until someone noticed. Ownership is now recorded in a way that survives the worker, so a lost attempt is detected and retried rather than silently abandoned.
- The settlement worker also gets its own deployment strategy: it fully drains the old pod before the new ones start, rather than running old and new side by side during a rollout. That matters because two versions of this particular worker overlapping is exactly the condition that produced orphaned work. Shared cache workers keep the normal rolling update, so this change does not slow down other deploys.