Use k6 events to handle browser lifecycle #944
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ka3de
force-pushed
the
feat/core-events
branch
5 times, most recently
from
07702be
to
a8145bc
Compare
ka3de
force-pushed
the
feat/core-events
branch
4 times, most recently
from
f10d8e7
to
334c8b3
Compare
In this way we reduce contention on sync.Map and avoid repeated string concatenation calls when generating the browser registry index, which was built based on VUID-scenario-iteration. Instead, tiying the browser registry scope to a single VU, we can use just the iteration as index for the registry.
This will allow for more flexibility on browser operations, for example during cleanup, on which all browser entries in the registry must be closed and deleted.
ka3de
force-pushed
the
feat/core-events
branch
6 times, most recently
from
8986bef
to
ebaae44
Compare
ankur22
reviewed
Jul 4, 2023
There was a problem hiding this comment.
Thanks for pushing this through and working with the k6 changes to get it to this final stage 👏
I think it mostly makes sense. I've left some questions that would help me understand the behaviour of the event system a bit more. Once those have been clarified though, i think we're good to go 🙌
This commit modifies the browser registry to subscribe to k6 'IterStart' and 'IterEnd' events in order to initialize and close the browser instances when receiving these events.
Adds a new event handler for the 'Exit' event, which is guaranteed to be fired before k6 execution exits, even in case of panic. Therefor this event is used to ensure all browser instances held at the VU registries are closed before finishing execution.
Instead, now browsers are only initialized and indexed in the registry as a reaction to 'IterStart' events. Therefor we can remove the getOrInitBrowser method from the mapping layer, and only call vu.getBrowser method in order to retrieve the previously initialized browser for the iteration.
As now it is only called from within the browser registry, and not from the mapping layer.
Now that browsers are not initialized or closed from the mapping layer, but as a reaction to iteration events from browser registry, we need helper functions for tests that require testing through the mapping layer so the browser for the executed iteration during the test can be previously initialized, and closed at the end of the iteration if necessary.
Use the vu.StartIteration helper in order to pre initialize the browser required for the iteration executed during the test, so once the JS and mapping layer code is executed, the browser instance can be correctly retrieved.
Add a higher level helper method to VU in order to retrieve the current VU iteration's browser instance. This improves the repetitive calls to getBrowser() method passing the current iteration as input from the mapping layer.
This will match our own go.mod version Also, this test was failing due to the usage of URL.JoinPath method in k6, which is only available since go v1.19.
ankur22
approved these changes
Jul 5, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
This PR integrates k6 browser, and more specifically our implementation of the browser registry, with the events generated from k6 (see grafana/k6#3112) in order to handle the browser lifecycle based on these events. Specifically:
IterStartevent.IterEndevent.Exitevent (which is the event guaranteed to be fired even on case of unexpected error).Closes #926.
Checklist