Make all Vert.x executeBlocking ordering requirement explicit

[jponge]

This ensures each call to executeBlocking defines its ordering needs instead of inadvertently falling back to strict ordering.

• Closes: Revisit Vert.x executeBlocking strict ordering by default #54088

[jponge]

Note: I've used my best judgement (most calls should use false so concurrency from the worker pool is used) but each extension expert should have a look. Also CI could reveal failing tests that I might have missed.

[Ladicek]

Is there a way to prevent using the API that makes the choice for you? I don't know how the ForbiddenAPI check works, but that might be an option? If we don't do that, it feels like we'll inevitably get it back in the future.

[jponge]

BytecodeTransformerBuildItem might be extreme, no? 🤣

[Ladicek]

ForbiddenAPI checks at compile time, which feels better than runtime to me :-)

[jponge]

I'm not sure which ForbiddenAPI you're talking about, do you have any pointer? I could stack a commit for that here.

[Ladicek]

We're already using this project https://github.com/policeman-tools/forbidden-apis in Quarkus, there's multiple references to it, grep for forbiddenapis. I think it should be possible to add the executeBlocking() signature(s) into .forbiddenapis/banned-signatures-common.txt and that should be it? (I'm saying "signatures", because we probably want to ban both Vertx.executeBlocking() and Context.executeBlocking().)

[geoand]

ForbiddenAPI checks at compile time, which feels better than runtime to me :-)

We've used ForbiddenAPI in various extensions haven't we?

[geoand]

We should definitely ban the version that doesn't require the boolean param

[geoand]

Makes sense, but others should look at their respective parts as well

[jponge]

I've added a ban list and fixed a few more call sites.

It will have to be reworked for Vert.x 5 as the executeBlocking APIs have changed.

[Ladicek]

I don't understand any of the modified code here, but the ban makes perfect sense to me 👍

[geoand]

integration-tests/hibernate-orm-graphql-panache looks like a genuine failure

[jponge]

@geoand I've rebased and tried locally, and integration-tests/hibernate-orm-graphql-panache work fine "on my machine". I'm going to push and see what CI says.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 50460d2.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[github-actions]

🎊 PR Preview 8201058 has been successfully built and deployed to https://quarkus-pr-main-54314-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.