Skip to content
This repository was archived by the owner on Jan 30, 2025. It is now read-only.

Conversation

imiric
Copy link
Contributor

@imiric imiric commented Aug 18, 2022

This is a functional change from before, since the iteration won't be interrupted by a timeout error anymore, and the promise will be rejected instead. This might be an acceptable tradeoff for using a lock, but it would be better if there was a way of interrupting the iteration if the promise is rejected.

Fixes #506

This is a functional change from before, since the iteration won't be
interrupted by a timeout error anymore, and the promise will be rejected
instead. This might be an acceptable tradeoff for using a lock, but it
would be better if there was a way of interrupting the iteration if the
promise is rejected.

Fixes #506
@imiric imiric requested a review from ankur22 August 18, 2022 08:13
@imiric
Copy link
Contributor Author

imiric commented Aug 18, 2022

@mstoykov Do you have an idea to improve this?

Previously we called k6's common.Throw() to interrupt the iteration, but we can't do that from a promise goroutine, if we want to avoid #506. Rejecting the promise still logs an error, but the iteration will continue.

@mstoykov
Copy link
Contributor

to interrupt the iteration

I do think the decision on whether the iteration should be interrupted should be of the user writing the test. They can do that through just on an exception/failure on this promise - abort the iteration :).

But IMO there are good reason for this to not be hardcoded like actually maybe retrying or doing other stuff when this fails. Maybe they need to free some resources 🤷 .

So as far as I am concerned this is a double bugfix :P

@imiric
Copy link
Contributor Author

imiric commented Aug 18, 2022

I'm not sure if the current failure of #509 is related to these changes or not... 😕

I've only seen it in tests so far, and we need to fix this issue, so I'll merge this and we can look into that later if it becomes a bigger problem.

@imiric imiric merged commit 3a1e01b into main Aug 18, 2022
@imiric imiric deleted the fix/506-concurrent-gojaruntime branch August 18, 2022 10:13
imiric pushed a commit that referenced this pull request Sep 2, 2022
imiric pushed a commit that referenced this pull request Sep 2, 2022
@imiric imiric mentioned this pull request Sep 2, 2022
ankur22 pushed a commit that referenced this pull request Sep 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Concurrent usage of goja.Runtime

3 participants