Route fallback keeps the handler chain.

A local test registers a response fixture and then an observer for the same endpoint. The observer calls continue() because its author wants the request to proceed. The fixture never runs. Instead, the request reaches the server. Both handlers look reasonable in isolation; their combined behavior depends on which method hands off control.

The Route API says matching handlers run in reverse registration order. The last registered handler gets the request first. fallback() passes it to the next matching handler; continue() sends it to the network immediately without invoking the other matching handlers.

Write the intended chain first

For an invented /demo-value endpoint, register the response fixture before the observer. This means the observer runs first and the fixture runs next. The fixture answers locally with a controlled string, so the endpoint's server handler should receive no call in that case.

const order: string[] = [];
await page.route('**/demo-value', async route => {
  order.push('fixture');
  await route.fulfill({ status: 200, body: 'fixture value' });
});
await page.route('**/demo-value', async route => {
  order.push('observer');
  await route.fallback();
});

This snippet assumes a page in a local test and a subsequent request to that endpoint. Assert both the returned string and the recorded order. A fixture value alone does not show whether an observer ran, and a handler log alone does not show what the page received.

Our local server counts calls to the endpoint. With fallback, the order is observer then fixture, the page gets fixture value and the server count remains zero. A separate fresh page uses continue in the observer. It gets server value, records only the observer and increments the server count once.

Keep each handler's exit visible

An observer may inspect a request and then delegate it. A fixture may fulfill it. A blocker may abort it. Give every path an explicit exit and avoid accidentally leaving a request waiting. If a conditional handler does not own a request, fallback lets another matching handler decide what happens next.

The API also supports request overrides while falling back. That changes the input seen later, so inspect those changes when reviewing a chain. Our demonstration uses no overrides, credentials or private headers. It isolates control flow rather than claiming to test header propagation.

A broad route can overlap with a narrow route. Read all registrations in the relevant setup, including shared helpers. A helper's registration time can make it run before a handler that appears earlier in the test file. Write the observed order into the failure report instead of assuming source layout establishes execution order.

Test the network boundary separately

A fulfilled route proves behavior under the supplied response. It does not verify the real provider. The continue case here reaches an invented local server, not a production service. Keep any supported integration check separate and use an approved environment for external traffic.

Fresh pages make the two specimens easier to interpret because each has its own registrations. If routes are changed within one test, remove the intended handler explicitly and wait for relevant work to finish. Cleanup must not silently alter the next case's network setup.

When reviewing generated code, list the endpoint, registration order, handler exits, response body and server evidence. AnyTest describes app exploration and reviewable tests. Use that review to ask which dependency answered the request. No particular AnyTest interception feature or handler implementation is claimed.