Handler fires beyond its triggering case

What goes wrong

A handler is attached at a wider scope than the narrow condition that justifies it, so it also runs for situations it was never designed for. The reader assumes the handler's reach matches the one case described when it was added.

Example

A recovery branch added for one unreadable record is wrapped around the whole loading routine, so any error inside it now takes the same drastic recovery.

Not to be confused with

Not a guard that checks the wrong property, and nearest to guard scope exceeds the operation's scope: here the condition is read correctly, and what is wrong is how much the response covers.

Discovered by

@sks24git GitHub

Field notes · 10

@sks24git2026-11-05

A fix for one missing file loosened a rule for every kind of missing file, not just the one that broke. Releases with a truly missing document could then pass as complete, which the spec forbids.

Fix the narrow cause, not the guard around it. A guard loosened for one case opens it for every case it covers.

@sks24git2026-11-05

A failure was marked "no other worker can do better" because one worker's own filters rejected every file. The retry then went nowhere, though the next worker in line reads files itself and would have done the job.

Ask whose limit a failure is before you skip the retry. One tool's filter is not the job's verdict.
Keep user-owned names out of server logs. Log a count, not the list.

@sks24git2026-11-04

A fix stopped one bad record from failing a whole list, but it caught per owner while records are read per year. One broken old year then hid the owner's good current data with no marker.

Catch at the grain you read. A coarser catch hides good rows silently.
Wrap only the failing call. A wide catch relabels unrelated errors.

@sks24git2026-11-02

A catch-all around an optional step also wrapped the part that runs after the paid work starts. A late error then looks like a skipped step, so a second paid worker starts in the same time slot.

Scope a fallback catch to the checks before the work starts. After that, a failure must not trigger the fallback.

@sks24git2026-10-30beat 1 review round

A batch job split into parallel calls kept the old all-or-nothing rule, so one failed call threw away every other call's good answer. The bigger the batch, the more calls, and the likelier it all came back empty.

Split the work, split the failure. When parts are independent, keep what succeeded and report what failed.

@sks24git2026-10-25beat 1 review round

A date helper now throws for years it has no data for, and one summary rule calls it while checking older reports. A single old file then crashes the whole check run, and every other result is lost.

Catch a new error where one rule calls it. One failing rule must not take every other result down with it.

@sks24git2026-10-17

A fix marks every result a later step reads as unknown, though that step can change only some of them. Firm yes and no answers turn unknown, and every check built on them stops deciding anything.

Mark unknown only what a later step can change. Wide unknowns hide real answers.
Trace where each value is set before you widen a rule. Names do not show order.

@sks24git2026-09-25beat 3 review rounds

A prompt filter built to remove a duplicate ran even on the path that adds no copy of its own. The client's full system prompt vanished there, and the tool ran with no instructions at all.

Run a dedup step only where the duplicate exists. Elsewhere it deletes the only copy.
Test every entry path a fix touches. One path had no test, so reverting it stayed green.

@sks24git2026-09-10beat 1 review round

A read was wrapped in a catch-all so an unreadable setting falls back to the seed, and that catch also swallowed the cancellation the loader rethrows on purpose. A cancelled request logged a config warning instead.

Never let a blanket catch eat cancellation. Rethrow it ahead of the fallback.
A fallback firing on shutdown means the catch is too wide.

@sks24git2026-09-06beat 9 review rounds

Storage was read on any identity mismatch and the slot removed, so user B's first closed mount deleted user A's unresolved retry. Under a feature the double-run consumed a once-ref with no cleanup.

Reads must not delete. A read path that cleans up on mismatch will erase a neighbour's state the first time identities differ.