A for/else scan of a shared document-conversion queue logs "nothing matched" when the list was actually empty — why, and how do you fix it?

The `else` clause of a `for` loop means exactly one thing: the loop was not exited by `break`. It does not mean "the search was exhaustive". Those come apart the moment the collection can be empty, because zero iterations is normal termination — the loop had nothing to break out of, so the `else` runs. A scan over a shared work list is precisely the case where the collection can be empty without anyone expecting it. ## Why the log line lies Take an eleven-worker document-conversion queue where each worker scans a shared list of pending jobs, `break`s on the first one it can claim, and whose `else` logs "nothing matched". Two very different situations produce that identical line. In the first, the list held jobs and none were claimable — real contention, and the right response is to back off and retry. In the second, another worker drained the list between the moment this one took its snapshot and the moment it iterated — the list was empty, the loop body never ran once, and the `else` fired anyway. The right response there is usually to block and wait for new work, not to retry a scan. Because the log line is the same, the operator's mental model of the system is wrong in a way no amount of staring at the loop reveals. The `else` is doing what it was defined to do; the code asked it a question it cannot answer. ## The fix ladder **Distinguish emptiness explicitly.** The smallest correct change is to stop asking the `else` to carry two meanings. Guard on the collection before the loop, or count what you examined, and report the two outcomes separately: "no candidates" and "candidates all busy" are different events, and they deserve different log lines, different metrics and different retry behaviour. **Extract the function.** Push the scan into a function that `return`s the claimed item, raises one exception type when there was nothing to look at, and another when everything was busy. The two failure modes become part of the signature instead of two paths converging on one branch. Callers can then handle them differently, which was the entire point. **Delete the scan.** The deeper problem in this scenario is not the `else` at all — it is that "find a free item" and "claim it" are two separate steps on state that other workers mutate in between. Even when the list is non-empty, two workers can both see the same job as free and both claim it; the loop `else` merely hides the diagnosis. Either make the check-and-claim atomic under a single `threading.Lock` held across both steps, or stop scanning shared mutable state and hand work out through a `queue.Queue`, whose `get` removes exactly one item per caller and blocks when the queue is empty. Blocking with a timeout also makes the "no work" case explicit and cheap, instead of eleven workers spinning through the same list. ## Reproducing it before you fix it The failure is timing-dependent, so the useful move in an interview is to say how you would pin it down rather than how you would guess. Log the length of the collection alongside the "nothing matched" line — a length of zero on that line is the whole proof, and it costs one field. If the two outcomes were already separated, the metric split shows it immediately. From there the fix is not a judgement call. ## What this generalises to The lesson is not "never use `for/else`". It is that the `else` answers "did a `break` happen?" and nothing else, so it is only a safe way to express "search failed" when the empty case is impossible or means the same thing to the caller. In a single-threaded function over an argument you validated on entry, that condition often holds. In any loop over state another thread, process or request can shrink, it does not — and the failure surfaces as a misleading branch rather than as a crash, which is why it survives testing and shows up in production. ## How to answer it Lead with the semantics, in one sentence: the `else` means no `break` occurred, and an empty iterable satisfies that trivially. Then name the operational consequence — two causes collapsed into one branch — and only then give the fix, cheapest first: distinguish the empty case, extract the function with two distinct failure types, and if the collection is shared mutable state, replace the scan with an atomic claim or a real queue. That ordering shows you diagnose before you refactor.