Stage 9 · L43

Find the first failed assumption using deliberate breakpoints

Core · original Session 9

Debugger workflow and launch configuration are authored; a live editor/debugger session has not been run.

Debug a failed assumption rather than stepping through every line. For capacity, the assumption is allocated + payload.quantity <= equipment.quantity after the shared row lock. Set a breakpoint around that comparison and inspect the actual stored allocation. Do not diagnose it from a stale browser quantity or an ORM object in a different session.

Step over executes a call in the current frame; step into enters the called function; step out returns to its caller; continue resumes to the next breakpoint or completion. Choose a tool based on the hypothesis. If a repository query is the suspect boundary, step into it; if its result is already known, step over keeps focus on the service.

A conditional breakpoint can use payload.quantity > equipment.quantity in the reserve frame. A hit count can pause only after a repeated operation. A logpoint can expose a carefully chosen nonsecret value without stopping, but it must not print password, JWT, database URL or full request. A dependent breakpoint is meaningful only after its preceding breakpoint has actually been reached.

Debugger evaluation can run code. Calling session.commit, a provider method or a property that lazily loads a relationship changes the system being observed. Prefer inspecting scalar values; lazy='raise' helps reveal accidental database work. Pausing while holding a FOR UPDATE lock also changes timing for other requests, so it is not a valid concurrency benchmark.

The automated two-thread test establishes the unpaused capacity invariant. The manual breakpoint exercise explains the values that lead to its201/409 decisions. Neither replaces the other. Record the selected process/frame and exact hypothesis when explaining a bug.

Expected: allocation + qty ≤ stock; Observed: locked row + actual sum; Pause in reserve service frame; Use condition/hit count carefully; Unpaused test proves201/409

Prepare the debugger

Focused lesson example; see the end-of-stage capstone for the cumulative app · stage 09

Hypothesis: allocated + requested <= stock under the shared lock
Inspect allocated, payload.quantity and equipment.quantity.
Condition: payload.quantity > equipment.quantity
Use a safe logpoint only for nonsecret scalar values.

Predict and observe this focused example using the concepts explained above. Its boundary is stated in the focused answer.

Guided lab

Read the explanation and predict the focused example’s outcome.
Find the first failed capacity assumption and choose a stepping action. Explain why calling commit or pausing under a lock changes the experiment.
Compare the observed outcome with the focused answer and state its boundary.

Expected: Inspect the service frame's stored inputs and choose step-into only at the uncertain called boundary; step-over known calls, step-out for returned values. A hit count narrows repeated visits; a dependent point waits for its predecessor. Evaluating commit mutates state, and pausing under a row lock changes timing. Use unpaused tests for concurrency evidence.

Evaluating side-effecting code changes the experiment; holding a row lock under a debugger changes concurrency timing.

Focused exercise and answer

Complete the manual exercise in your learner repository and record which checks actually ran.

Your transfer task: Find the first failed capacity assumption and choose a stepping action. Explain why calling commit or pausing under a lock changes the experiment.

Find the first failed capacity assumption and choose a stepping action. Explain why calling commit or pausing under a lock changes the experiment.

Inspect the matching answer

This answer addresses the focused exercise above; the cumulative implementation is shown only after the stage prerequisites.

Inspect the service frame's stored inputs and choose step-into only at the uncertain called boundary; step-over known calls, step-out for returned values. A hit count narrows repeated visits; a dependent point waits for its predecessor. Evaluating commit mutates state, and pausing under a row lock changes timing. Use unpaused tests for concurrency evidence.

Check your reasoning

Is paused debugger timing a valid latency benchmark?

Show the explanation

No. Use it to inspect a hypothesis; measure behavior with normal unpaused execution.

Reading progress

54 lessons remain open to guests. Marking a lesson read records reading only; it does not award assessment credit or a certificate.

Device reading marks require browser storage. Reading is always available.