-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change how group()
calls async functions
#2848
Labels
Comments
mstoykov
added a commit
that referenced
this issue
Jan 19, 2023
A group provided with an async function will now: 1. Treat the whole time it take for the async function promise to finisher the duration of the group. 2. It will also use goja's AsyncContextTracker to make it so that the code using `await` within the group will still continue to be tagged with the group after `await` returns. 3. Instead of directly calling the async function it schedules it to be called the next time a promise job will work. The current AsyncContextTracker is only used for this and as such is directly changed in the `k6` module. In the future there likely will be API so that multiple modules can use it simultaneously, but that seems way too involved to be included in this change and also currently only `group` needs this. fixes #2848 #2728
mstoykov
added a commit
that referenced
this issue
Jan 19, 2023
A group provided with an async function will now: 1. Treat the whole time it take for the async function promise to finisher the duration of the group. 2. It will also use goja's AsyncContextTracker to make it so that the code using `await` within the group will still continue to be tagged with the group after `await` returns. 3. Instead of directly calling the async function it schedules it to be called the next time a promise job will work. The current AsyncContextTracker is only used for this and as such is directly changed in the `k6` module. In the future there likely will be API so that multiple modules can use it simultaneously, but that seems way too involved to be included in this change and also currently only `group` needs this. fixes #2848 #2728
mstoykov
added
the
evaluation needed
proposal needs to be validated or tested before fully implementing it in k6
label
Jan 26, 2023
Blocked on #2728 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
As of #2830 k6 has support
async
functions.A such the following code is now valid
And will print
A, C, B
(with new lines in between).This is okay but after an internal poll most people expect
C, A, B
- running the remaining parts before calling theasync
function.Given that irregardless of what people expect the returned value of
group
will be a promise so in order to get it the stack will need to be empty.It seems more reasonable to not have some parts of the
group
finish before continuing and some to finish.Proposed solution:
Have
group
recognise that it got an async function. And queue it's calling (with the appropriate setting ofgroup
tag) on the event loop. Or create another promise that immediately is resolved and do the actualgroup
call in the resolution callback.The difference between the two is that using a promise this will be called before anything else that will be called from the event loop. And as such also before any other immediately resolved promise created after the call to
group
.So the difference in example is:
Wil in the one case write
C, D, A, B
in the otherC, A, D, B
.C, D, A, B
as the resolved promise will be executed before anything from the k6 event loop can be executed.C, A, D, B
as the promise resolution of thegroup
will be queued before theD
one but then the await will once againRecognising it seems to be possible if we take the callback argument as
goja.Value
and get its Prototype.FAQ:
Why not
A, B, C
?This is currently possible if the code is
Which also requires that the code is within an async function in order for
await
to not be a syntax error.This will still be possible after that as well.
Is this a breaking change?
Given that
async function
was not supported up until this point - I would argue not. AFAIK the ways to polyfill this does not return the same Prototype so that will still work the same way as before.The text was updated successfully, but these errors were encountered: