Move taskqueue to mapping layer #1069

Removes the goja TaskQueue from the page implementation and instead places it in the mapping layer by wrapping the handler in a function that will execute it in the local TaskQueue.

It's no longer required to return an error from the handler, as this is handled in the TaskQueue wrapper in the mapping layer. This change also refactors the test so that: 1. it no longer returns an error from the handler; 2. the event loop has been removed since the taskqueue has been removed from the business logic, making the test simpler to understand with less orchestration.

With this change we only use the TaskQueue from the main thread, as it's required to avoid race conditions with goja. Unfortunately this implies an explicit close call for the TaskQueue that we are wrapping in the page.close() call in the mapping layer.

To enable us to work with the task queue outside of the business logic and allow the setup of the predicate function within the task queue we need to: 1. Parse the options in the mapping layer. 2. Create a func that can call the predicate function from within a taskqueue. 3. We need to wait for the taskqueue call to complete and return the response back to the caller. 4. Change the browserContext API within the go code.

This refactors the tests so that it matches the new signature for waitForEvent, which is that it takes in a predicate method and a timeout. The predicate method will now be wrapped and added to a taskqueue in the mapping layer which means we do not need to work with the event loop in the test itself. Since the options are now parsed in the mapping layer, this also simplifies how we pass the predicate and timeout arguments to waitForEvent.

This is just cleaning up the arguments so that they are grouped in a better way, as well as shortening the line length to avoid the linter issue.

Since waitForEvent is a promisified function, we need to make the taskqueue thread safe.

The taskqueue wasn't working when it was one per vu since it became difficult to understand exactly when it was best to close the taskqueue if there were multiple pages. This change now creates a taskqueue per page, but the taskqueues is stored in the vu rather than in the page struct itself, which helps ensure that the taskqueue is kept away from the page business logic.

This will be used to register, retrieve and close the taskqueues which is required by the page.on and browserContext.waitForEvent APIs.

Since a require.True will FailNow in the current goroutine and not the root goroutine of the test, it's best to pass an error back to assert on in the test's root goroutine.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Move taskqueue to mapping layer #1069

Move taskqueue to mapping layer #1069

Commits on Oct 23, 2023