Prompt and scope
A team wants to migrate browser network interception from a private debugging protocol to WebDriver BiDi. Explain how you would design session setup, event subscriptions, interception lifecycle, concurrency isolation, and failure recovery.
What the interviewer evaluates
- Understanding that BiDi is WebDriver's bidirectional, event-driven protocol and remains a W3C Working Draft.
- Distinguishing session, context, intercept id, request id, and event-subscription responsibilities.
- Scoping interception by URL pattern, phase, and context to prevent cross-test contamination.
- Designing timeouts, cancellation, disconnect handling, and redaction instead of presenting only a script.
Clarifying questions
- Does the test observe traffic, or modify/block it at request or response phases?
- Do the browser, driver, and runtime support the required BiDi modules?
- Does each test own a browser context, and how long are rules and event logs retained?
- On failure, should real networking be restored or should the test fail immediately with diagnostics?
30-second answer framework
For each test I would create an isolated BiDi session and browsing context, negotiate capabilities, and subscribe only to needed events. Rules would constrain URL, phase, and context; events such as beforeRequestSent would lead to one decision per request id: continue, block, or provide a mocked response. Every rule has a timeout and cleanup hook. A disconnect stops mutation and fails the test as infrastructure, while logs retain only redacted metadata. Production traffic never uses this interceptor.
Step-by-step deep dive
1. Confirm protocol and implementation boundaries
WebDriver BiDi uses WebSocket for bidirectional, event-driven communication; the W3C 1 June 2026 version is still a Working Draft. The client should read driver and browser capabilities rather than assume draft fields are stable everywhere. Classic WebDriver HTTP commands can coexist with BiDi events, but one channel must be the authority for each piece of state.
2. Create isolated sessions and contexts
At test start, create a session and an isolated browsing context, and record the session, context, and test run id mapping. Give each interception rule a unique intercept id and bind it only to the needed URL patterns, phases, and context. At teardown, unsubscribe, remove intercepts, and close the context in reverse order so rules cannot leak into the next test.
3. Design event and interception decisions
Subscribe to network events with session.subscribe, then use the request id in each event to locate test state. A hit gets exactly one explicit action: continue, block, or provide a response at a supported phase. The decision layer needs an idempotency key and timeout. Unknown request ids, duplicate events, or unsupported phases go to observable errors rather than silent continuation.
4. Handle concurrency, disconnects, and security
Concurrent tests must not share a mutable intercept table; each context owns its rules and event buffer. On WebSocket disconnect, stop modifying traffic, mark the test as infrastructure failure, redact and retain the URL, status, and timeline, then clean up. Redact headers, cookies, bodies, and tokens by default. Run only in test browsers with short-lived test credentials, never against production domains.
High-quality sample answer
I would treat BiDi as a protocol boundary, not copy a route API from one automation library. Each test gets an isolated session and browsing context, reads capabilities, and subscribes to the required network events. Intercepts have unique ids and are limited by URL pattern, phase, and context; events use request ids to make one continue, block, or mock decision. Teardown unsubscribes, removes rules, and closes the context in reverse order. Every action has a timeout, idempotency, and diagnostic record. A WebSocket disconnect fails the test as infrastructure and cleans up rather than mutating traffic in an unknown state. Logs are redacted, test browsers are isolated from production, and compatibility differences are explicit in a capability matrix.
Common mistakes
- Treating Working Draft fields as stable APIs in every browser and driver.
- Intercepting globally by URL without context, phase, or test-run scoping.
- Failing to subscribe first, or mixing event, intercept, and context ids.
- Continuing to send mutations after a disconnect, making results uninterpretable.
- Leaving intercept rules active after teardown and contaminating later tests.
- Writing cookies, Authorization, or response bodies to logs unchanged.
- Enabling a test interceptor in production browsers or real user traffic.
Follow-up questions and answers
How can BiDi coexist with classic WebDriver?
Classic WebDriver suits imperative control, while BiDi suits continuous events and network observation. They can share a browser session, but state ownership and shutdown order must be explicit so both channels do not mutate one context at once.
Why do interception rules need a phase?
The available data differs before a request is sent, when a response starts, and when it completes. A phase selects what can be changed and allows unsupported phases to fail early instead of being guessed at runtime.
How do you prove there is no cross-test contamination?
Give every test its own context and intercept ids, query and clear that context's rules at teardown, and run an isolation check. Record subscribe, cancel, and close events so a failure retains a complete timeline.