fix(core): surface abort reasons in errors#41752
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4700825d-f132-4fcc-ba57-109da3fb9e77
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4700825d-f132-4fcc-ba57-109da3fb9e77
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
dgozman
left a comment
There was a problem hiding this comment.
I think this PR would really benefit from before/after error snippets for click/expect that failed due to timeout/abort/strict violation error.
|
|
||
| async abort(error: Error) { | ||
| const causeMessage = error.cause instanceof Error ? error.cause.message : error.cause === undefined ? error.message : String(error.cause); | ||
| const logMessage = `operation was aborted: ${causeMessage}`; |
There was a problem hiding this comment.
I think this will also be printed for timeout errors?
There was a problem hiding this comment.
no, abort is used exclusively for __abort__ (signals) and for the aborts upon connection closed. Test ended errors go via context.close and abort through scope closure, not through this code path.
|
|
||
|
|
||
| async abort(error: Error) { | ||
| const causeMessage = error.cause instanceof Error ? error.cause.message : error.cause === undefined ? error.message : String(error.cause); |
There was a problem hiding this comment.
So it seems like cause is more important than error.message itself? Seems strange.
There was a problem hiding this comment.
oops that was a remnant, fixed.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4700825d-f132-4fcc-ba57-109da3fb9e77
Test results for "tests 1"5 flaky49544 passed, 1168 skipped Merge workflow run. |
Test results for "MCP"1 failed 7759 passed, 1249 skipped Merge workflow run. |
This PR keeps the supplied
AbortSignalreason in API error messages and call logs. Aborted locator assertions now retain their latest mismatch detail instead of replacing it with an assertion-aborted message.I ran the same click/expect repros against the merge base and this branch. Only the abort output changes.
locator.click()when aborted:expect(locator)when aborted:Error: expect(locator).toBeVisible() failed Locator: locator('span') Expected: visible -Error: The assertion was aborted: stop it +Error: element(s) not found Call log: - Expect "to.be.visible" with timeout 5000ms - waiting for locator('span') + - operation was aborted: stop itI also verified that operation timeouts, test timeouts, and strict-mode violations are unchanged.
Split out of #41751.