Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Principle:Getgauge Taiko Intercept Management

From Leeroopedia
Revision as of 18:09, 16 February 2026 by Admin (talk | contribs) (Auto-imported from principles/Getgauge_Taiko_Intercept_Management.md)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Template:Principle

Overview

Intercept Management is the technique for removing previously registered request interceptors to restore normal network behavior during automated testing with Taiko.

Description

Intercept management provides cleanup operations to remove specific or all registered interceptors. This is essential for maintaining test isolation — interceptors registered in one test must not affect subsequent tests. Without proper cleanup, interceptors accumulate across tests and can cause unexpected blocking, redirecting, or mocking of requests in later test scenarios.

The management operations support two modes:

  • Targeted removal — Remove a specific interceptor by providing the URL pattern that was used during registration. This is useful when only certain interceptors need to be cleaned up while others should remain active.
  • Bulk reset — Remove all registered interceptors at once by calling the cleanup function with no arguments. This is the safest approach for test teardown, ensuring a completely clean interception state.

Usage

Intercept management is used in the following scenarios:

  • Test teardown — Clear all interceptors at the end of each test to prevent cross-test contamination
  • Mid-test cleanup — Remove specific interceptors when the test scenario transitions from one phase to another (e.g., first mock an API response, then allow real requests)
  • Suite-level cleanup — Clear all interceptors between test suites to ensure a fresh state
  • Error recovery — Remove interceptors that may have been left behind by a failed test

Best practices for intercept management:

  • Always clear interceptors in test teardown hooks (afterEach, afterScenario)
  • Prefer bulk reset over targeted removal in teardown to avoid missing stale interceptors
  • Clear interceptors before registering new ones if the test relies on a specific interception state

Theoretical Basis

The interceptor registry is maintained as an in-memory collection within the fetch handler:

Interceptor Registry (Map: urlPattern → interceptor)
        │
        ├── clearIntercept(urlPattern)
        │       │
        │       ▼
        │   Remove entry matching urlPattern from registry
        │       │
        │       ▼
        │   Subsequent requests to urlPattern proceed normally
        │
        └── clearIntercept()  (no arguments)
                │
                ▼
            Clear entire registry
                │
                ▼
            All requests proceed normally (no interception)

The registry uses URL patterns as keys. When clearIntercept is called with a URL pattern, the corresponding entry is removed from the registry. When called without arguments, the entire registry is cleared.

Note that clearing interceptors does not disable the CDP Fetch domain — it remains enabled so that new interceptors can be registered without re-initialization. Requests that do not match any registered interceptor are automatically continued via Fetch.continueRequest.

The cleanup operation is synchronous and takes effect immediately. Any requests that are already paused and waiting for a handler decision are not affected — only future requests will see the updated interceptor state.

Related Pages

Implemented By

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment