When should a drain loop's termination be guaranteed structurally by a hard bound rather than trusted to the data source?
answer
- ask who owns the measure
- internal versus external guarantee
- an unenforceable contract is an assumption
- prefer a per-pass progress check
- the trip must not truncate silently
basics
~20 sWhenever the termination measure depends on a party you do not control, termination is an assumption about the environment rather than a property of your code. Bound it structurally, and make the bound report a failure instead of silently truncating the result.
solid answer
~50 sThe deciding question is who owns the measure. If the quantity that must strictly decrease is internal — a window shrinking, an index walking a fixed collection — termination is a theorem about your own code and a cap adds noise without adding safety. If the measure depends on a remote source choosing when its pages end, your proof is conditional on a contract you cannot enforce, and a violated contract becomes a stuck worker holding its resources. Then bound it: a maximum pass count, a required strict advance of the cursor per pass, or both. The judgment that matters is not whether to bound but **what the bound does when it trips**. A cap that breaks out quietly converts a hang into a silently incomplete result — usually the worse failure, because downstream systems act on it. Trip loudly, with the measure's value in the error.
go deeper
Notice that a loop waiting on data from elsewhere can run forever if that source misbehaves, which is not true of a loop walking a fixed collection.
Explain why the termination measure of a loop over a remote source is owned by that source, and what a per-pass progress check verifies that a pass cap does not.
Add the enforcement: assert the strict decrease, fail with the measure's values, and make sure a truncated result can never be mistaken for a complete one.
Own the policy. Decide which boundary loops must be structurally bounded, what a tripped bound does to the job's reported outcome, and how the team avoids caps becoming routine noise.
## The question behind the question Every loop that terminates does so because some quantity descends to a floor. The design decision is **who guarantees that descent**. There are only two answers, and they carry different risks. - **You do.** The measure is built from state your code owns — a window's width, an index over a collection whose size is fixed before the loop starts. Termination is then a property you can prove once and rely on. A hard cap here is dead weight: it can only fire when your own reasoning is wrong, and it will be tuned by guesswork. - **Someone else does.** The measure depends on a source deciding when to stop producing pages, a peer deciding when to stop sending, or data whose shape you did not create. Your proof has the form "terminates provided the contract holds". That is an honest proof of a conditional claim — and the condition is outside your test suite. ## Why the second case deserves a structural bound A violated termination contract does not surface as an error. It surfaces as absence: a worker that never reports, a slot in a pool never returned, a lock held indefinitely, an operator eventually noticing that throughput is down. Detection is slow precisely because nothing failed. Weigh that against the cost of a bound, which is a constant and a branch. Three bounds are available, and they are not equivalent. | Bound | What it enforces | What it costs | |---|---|---| | Maximum pass count | A ceiling unrelated to the real measure | A magic number that ages badly and hides the cause | | Required strict advance per pass | The actual measure obligation, checked | Needs the measure to be nameable and cheap to evaluate | | Deadline on the whole loop | Containment of elapsed time only | Says nothing about which pass went wrong | The middle one is the strongest by a wide margin, because it checks the very obligation the proof needs: the cursor strictly advanced, the remaining count strictly fell. It fails on the first bad pass, with the state that caused it still in hand, instead of after some arbitrary number of good ones. ## The decision that is actually hard Not whether to bound, but **what the bound does when it trips**. A cap that breaks out of the loop converts a liveness failure into a completeness failure: the job finishes, reports success, and the sink is missing records nobody knows about. Downstream systems then act on a partial result, and the damage propagates further than a hang would have. That trade is occasionally right — a best-effort scan where partial data is genuinely useful — and it is right only when the partiality is visible in the output, not swallowed. Default the other way: when the bound trips, raise. Include the measure's last two values and the pass count. The bound then behaves as a detector of a broken contract rather than as a way to live with one. ## How to decide, in order 1. **Name the measure.** If nobody can, that is the finding, and the loop has no termination argument at all. 2. **Ask who owns it.** Internal means prove it and move on. External means the proof is conditional. 3. **Write the condition down** as an explicit assumption about the source's behaviour, so it is reviewable rather than implicit. 4. **Enforce the assumption** with a per-pass progress check, not a distant cap, wherever the measure is cheap to evaluate. 5. **Choose the trip behaviour deliberately**, and make a truncated result impossible to mistake for a complete one. ## Costs to keep honest about - **Bounds everywhere become noise.** Applied to loops whose measure is internal, they dilute the signal and teach reviewers to skim past them. - **A bound can mask a real defect** if it trips routinely and is merely logged. A bound that fires in normal operation is a bug report nobody filed. - **A tuned cap is a guess with a number on it.** Prefer a check derived from the measure, whose threshold is "did it decrease" rather than "is it under a thousand". - **Retries interact badly.** A retry that restores the previous state resets the measure, so a loop with retries inside it may have no descent at all even though each individual branch looks like progress. ## What a strong answer sounds like A candidate at this level does not answer "always add a cap". They separate the two ownership cases, prefer the progress check to the arbitrary ceiling, and spend most of the answer on trip behaviour — because that is where the choice between a visible failure and a silent wrong answer is actually made.
- Why is a per-pass progress check usually better than a maximum pass count?Because it checks the obligation the proof actually needs — that the measure strictly decreased — rather than a ceiling invented beside it. It fires on the first offending pass with the responsible state in hand, and its threshold never needs tuning, whereas a pass cap ages with data volume and hides which pass went wrong.
- When is silently truncating at the bound the right choice?Only where partial output is genuinely useful and the partiality is visible to the consumer — a best-effort scan that reports how far it got, for instance. Even then it is not silent: the result carries a marker saying it was cut short. Success reported over a short read is the failure mode to design out.
- Do retries inside the loop body affect the termination argument?Significantly. A retry that restores prior state and re-enters leaves the measure unchanged for that pass, so a loop that looks like it progresses may have no descent at all. Either the retry lives inside one pass with its own bounded measure, or the outer measure must be defined so retries still decrease it.
saying these in an interview costs you the question
- Says every loop should carry a maximum iteration cap
- Breaks out at the cap and reports the job as successful
- Assumes a remote source always eventually signals exhaustion
- Treats a deadline as equivalent to a decreasing measure
- Tunes a cap by guesswork instead of checking progress
- Logs a tripped bound routinely without treating it as a defect