One rule about holidays lived in twelve places and gave two answers

Two reports, one day, two answers

A nightly absence check and a month-end report disagreed about the same day. One treated an unconfirmed calendar entry as a holiday, the other as a working day, and one of them emailed a manager.

Where it touched money

In a leave plan, an unconfirmed entry inside the window meant an employee was absent for 11 working days and charged for 10. In the recovery ledger, the code discarded overtime that people had really worked.

The ticket described that second one the wrong way round, as overtime credited that was never worked. We measured it: a test applied 2.0 hours and the old code applied 0.0. The employee was under-credited, not over-credited.

Why the first search missed it

The first census looked for the name of the helper that filters the calendar. It cannot find a reader that never calls the helper. A broad search over every query on the holiday table gave 22 lines and found four more readers, one of which was dead code and was deleted.

One of them was a public endpoint that listed entries an admin had rejected, with their dates and titles. That is a disclosure, not just a miscount.

What we changed

We renamed the helper so that it says what it now does, approved entries only, and every caller had to choose. The diff became the census. Twelve places in all decided the rule: four already answered approved-only, and the eight that did not were brought in line. Dead code found on the way was deleted after checking its history and that nothing called it.

There is deliberately no lenient twin of the helper. The one screen that needs unconfirmed entries goes through its own query.

What to take from it

• Search for the data, not the helper. A reader that skips your helper is the one you need.
• Measure the harm. Our first description of the ledger bug was backwards.
• Make callers choose. A rename forces the decision at every call site.