asking for a day that cannot have data
A daily step selected its working day by taking the calendar date before today. On most days that is right. On the day after the weekly close it is wrong by construction: the chosen date has no data and never will. The step ran, found nothing, reported nothing, and exited successfully. Every week, one day produced a silence indistinguishable from a quiet one.
The repair walks back from the requested date to the most recent completed trading day inside a declared bound, and the same walk was applied to the wider pipeline so that a day label resolves the same way on both sides. It is a small piece of arithmetic whose absence is invisible, because the run succeeded.
The second half of the same change is what generalises. The corrected logic had been living only on the live machine — patched in place, never committed. It was committed and then redeployed from the record, on the reasoning that a fix which exists in one place is one reinstall away from being lost.
The change also declared its dependency: a companion fix in the data layer had not shipped, and the record says so, so that a silent night afterwards could not be blamed on the part already in.
What it proves: they hunt the failures whose symptom is a clean exit, and they treat an uncommitted fix as a defect in its own right.
drawn from: a scheduling fix that was also found living on one machine only
Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.