Fix other.test_jspi_async_function. NFC

[sbc100]

There was a race between #24550 and #24578 resulting in this test failing when it was landed.

[RReverser]

Thanks.

[RReverser]

I think we should enable merge queue for Emscripten.

We used it in another project and it saves from conflicts like this one whenever you have many contributors "racing" at once.

[sbc100]

I think we should enable merge queue for Emscripten.

We used it in another project and it saves from conflicts like this one whenever you have many contributors "racing" at once.

Yes, but...

1. This really doesn't happen very often (maybe once ever 3 months or so?)
2. Our tests are pretty slow and flaky. It could be really annoying to have all of my active PR's have to re-start/re-run tests when one of them happens to land... I can see myself using the override a lot of avoid having to wait another 1+ hours for each PR.

[RReverser]

2. Our tests are pretty slow and flaky.

Heh it would have opposite impacts on two parts of this.

Re:slow - a merge queue would help with that as it would run the entire suite once instead of separately to merge each PR.

OTOH because they're flaky, yeah, it would mean it would cancel entire group of PRs at once as well. That does need to be addressed...

[sbc100]

2. Our tests are pretty slow and flaky.

Heh it would have opposite impacts on two parts of this.

Re:slow - a merge queue would help with that as it would run the entire suite once instead of separately to merge each PR.

If we don't run the test suite on PRs/commits this can break bisecting can't it? And lower the confidence we have in any one single PR?

OTOH because they're flaky, yeah, it would mean it would cancel entire group of PRs at once as well. That does need to be addressed...

[sbc100]

Hmm, have you used this feature much? From reading the docs it does sounds like each PR would get the full set of tests run on it before merging any of them, is that right?

Also, what happens if I update PR that happens to be in the middle of the queue somewhere? I assume this would push be to the back of the queue, and force any PRs that were behind me in the queue to have their tests re-run?

[RReverser]

If we don't run the test suite on PRs/commits this can break bisecting can't it?

Only if you've got two PRs somehow in the same queue (for that they have to be "merged" concurrently) where one of them breaks something and another happens to fix the very same thing, so applied together they "cancel out" and the entire queue passes CI even though individual PRs wouldn't. That's extremely unlikely, especially since, like you said, we don't get concurring PRs often in the first place.

Also, what happens if I update PR that happens to be in the middle of the queue somewhere? I assume this would push be to the back of the queue, and force any PRs that were behind me in the queue to have their tests re-run?

I think that's correct.

[sbc100]

Only if you've got two PRs somehow in the same queue (for that they have to be "merged" concurrently) where one of them breaks something and another happens to fix the very same thing, so applied together they "cancel out" and the entire queue passes CI even though individual PRs wouldn't. That's extremely unlikely, especially since, like you said, we don't get concurring PRs often in the first place.

Actually, from my reading of the docs it looks like the test need to pass at each individual PR, not just the combined total, right?

[RReverser]

I think they're distinct. Same as with single PRs (in normal workflow) you have separate checks for PR itself and separate for merge commit, with merge queue you'll still have separate check for PR itself unless disabled, and then separate for the entire merge group aka merge commit, by using this trigger. https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows

[sbc100]

I think they're distinct. Same as with single PRs (in normal workflow) you have separate checks for PR itself and separate for merge commit, with merge queue you'll still have separate check for PR itself unless disabled, and then separate for the entire merge group aka merge commit, by using this trigger. https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows

I see, but the checks that happen for each PR are in isolation and don't contain PRs that are ahead in the queue? That makes some sense I suppose.

[RReverser]

but the checks that happen for each PR are in isolation and don't contain PRs that are ahead in the queue

Yeah, they run independently from whether PR is in merge queue or not.