This change fixes an issue whereby the browser module could block a test abort if the browser module was in the middle of waiting on something e.g. working with waitFor* apis.
The fix is to use the VU context for the iteration, but keep to the background context for running the chromium subprocess and connections. Now when the test is aborted, the vu context is closed by k6, which in turn will cancel all running browser API calls, and finally allow k6 to shutdown the test.
Why?
It was blocking the test from aborting. The reason was due to the use of the background context for the iteration as well as for running the browser subprocess and connection. k6 signals a test abort by cancelling the VU context, but since the browser module wasn't relying on that, the browser module would first complete the exiting API call/iteration before realising that the test was aborted.
We need to work with both the VU context to control the iteration lifecycle, and the background context so that we allow the k6 event system to control the chromium subprocess/connection lifecycle. They need to be separate to prevent race conditions when working with the chromium subprocess/connection.
Checklist
[X] I have performed a self-review of my code
[ ] I have added tests for my changes
[x] I have commented on my code, particularly in hard-to-understand areas
What?
This change fixes an issue whereby the browser module could block a test abort if the browser module was in the middle of waiting on something e.g. working with
waitFor*apis.The fix is to use the VU context for the iteration, but keep to the background context for running the chromium subprocess and connections. Now when the test is aborted, the vu context is closed by k6, which in turn will cancel all running browser API calls, and finally allow k6 to shutdown the test.
Why?
It was blocking the test from aborting. The reason was due to the use of the background context for the iteration as well as for running the browser subprocess and connection. k6 signals a test abort by cancelling the VU context, but since the browser module wasn't relying on that, the browser module would first complete the exiting API call/iteration before realising that the test was aborted.
We need to work with both the VU context to control the iteration lifecycle, and the background context so that we allow the k6 event system to control the chromium subprocess/connection lifecycle. They need to be separate to prevent race conditions when working with the chromium subprocess/connection.
Checklist
Related PR(s)/Issue(s)
Updates: https://github.com/grafana/xk6-browser/issues/1410