Skip to content

fix: fail when acting on the browser after an expected exception - #207

Open
Amoifr wants to merge 1 commit into
zenstruck:1.xfrom
Amoifr:fix-202-stale-state-after-expected-exception
Open

fix: fail when acting on the browser after an expected exception#207
Amoifr wants to merge 1 commit into
zenstruck:1.xfrom
Amoifr:fix-202-stale-state-after-expected-exception

Conversation

@Amoifr

@Amoifr Amoifr commented Aug 25, 2026

Copy link
Copy Markdown

Fixes #202

Implements the proposal from the issue, in the shared layer so both browsers get the same behavior:

  • Driver::wrapRequest() records that the expected exception was consumed (the flag is cleared by the next request and by reset()).
  • Session::ensureNoException() already runs before every action and assertion, so it now fails fast with "The last request threw the expected exception: make another request before continuing." instead of leaking BrowserKit's BadMethodCallException or silently acting on the previous page.

The shared test covers the three cases from the issue: stale previous page, no previous request at all, and recovery once another request is made.

Thanks for writing the issue up with the proposal included, it basically reviewed itself. 😄

After expectException() and a request that throws, the throwing request
never produced a response, so the client still holds the state of an
earlier request (or none at all). Actions and assertions then either
leak a raw BadMethodCallException from BrowserKit or silently run
against the previous page.

wrapRequest() now records that the expected exception was consumed and
ensureNoException() fails the next action with an explicit message
until another request is made.

Fixes zenstruck#202
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Acting on the browser after expectException() works on stale state

1 participant