Finding Which Step Failed in a Scenario

Quick answer: When a scenario fails, the run reports the failure against the exact step and assertion that broke, not just that the flow failed. Use the ordered step number, the named check, and the raw response at that step to diagnose the cause without replaying the whole chain. The engine streams progress as it runs, so you can see how far the flow reached before the failure.

Why a pointed failure matters

A long flow can span many requests, and a generic failure message leaves you to walk every call to find the defect. That is slow and error-prone, especially when the real cause sits several steps before the final request. A scenario is built to keep the failure tied to a specific step.

• Each step has a fixed position in the ordered sequence.
• Every assertion belongs to the step that evaluates it.
• A failed check is reported with the step number and the response it produced.

This turns a long chain into a short diagnosis: the failure names the request, the check, and the raw output.

What the failure evidence contains

When a step breaks, the run gives you the pieces needed to explain it.

Reading the raw response first is usually the fastest path, because a wrong status or an unexpected field is visible at a glance. Then trace the extracted variables to see whether an earlier step handed over a bad value.

A diagnostic sequence

Work from the named step rather than restarting the run blindly.

1. Read the failed step number and the assertion that did not hold.
2. Inspect the raw response at that step.
3. Check the variables the step received from earlier requests.
4. If the input was wrong, move to the earlier step that produced it.
5. Fix the root cause and rerun, letting the idempotent flow re-verify.

A common pattern is a failure that looks like a step-three defect but really begins at step one, where a token or id was extracted with the wrong shape. Tracing the variables back leads you to the source instead of fixing the symptom.

When the failure is a 200

A step can return 200 and still fail a field assertion or break the contract, because the status says the call was accepted, not that the body is correct. The named assertion catches that case and keeps the green status from reading as success. If the failure is inconclusive rather than a hard fail, it means verified evidence is missing, not that the step passed.

The engine runs connected requests in the main process with streamed progress and a cancel action, so a hung run can be stopped instead of blocking the diagnosis.

Powerduck keeps the step-level evidence and raw output attached to the failure, so you can see the exact request and check that broke rather than parsing a single red label.

Frequently asked questions

Do I need to rerun the whole flow to find the failure? No. The run names the failed step and assertion, and carries the raw response and extracted variables, so you can diagnose from that evidence first.

What if the failed step received a bad value? Trace the variable back to the earlier step that produced it. The root cause often sits one or more requests before the step that reported the failure.

Can a 200 response be a failure? Yes. A 200 with a wrong or missing field fails a field assertion, and a response that breaks the contract is caught even when the status is green.

The bottom line

A scenario earns its keep when a failure points at the exact step, assertion, and raw response that broke. Start from the named step, inspect the output, and trace the extracted variables back to their source rather than replaying the whole chain. Keep in mind that a 200 can still fail a field check, and that an inconclusive result means missing evidence, not a pass. The faster you can name the step that broke, the faster the flow gets fixed. Read more in the API scenario testing guide.