Delaying a `Uni` should not move the context to an executor thread in Quarkus

[wjglerum]

When writing some reactive code you can delay a Uni by a certain duration:

Uni.createFrom().item("item").onItem().delayIt().by(Duration.ofSeconds(1))

See https://smallrye.io/smallrye-mutiny/latest/guides/delaying-events/

If you then start combining this with Hibernate Reactive you will get big stacktraces telling you not to do this as it's not allowed.

HR000069: Detected use of the reactive Session from a different Thread than the one which was used to open the reactive Session - this suggests an invalid integration; original thread [222]: 'vert.x-eventloop-thread-2' current Thread [214]: 'executor-thread-1'

And the error is correct, as the delay gets scheduled on a worker thread and not on the event loop, see https://github.com/smallrye/smallrye-mutiny/blob/main/implementation/src/main/java/io/smallrye/mutiny/groups/UniOnItemDelay.java#L34

I created a small reproducer based on a quickstart to showcase this, see quarkusio/quarkus-quickstarts@main...wjglerum:panache-transaction-delay

Here you can see that after the delay it now runs on a worker thread:

2025-11-05 16:12:32,724 INFO  [org.acm.hib.orm.pan.FruitResource] (vert.x-eventloop-thread-2) Fruit<1>
2025-11-05 16:12:33,730 INFO  [org.acm.hib.orm.pan.FruitResource] (executor-thread-1) Fruit<1>

After discussing on Zulip (see https://quarkusio.zulipchat.com/#narrow/channel/187030-users/topic/Quarkus.20Hibernate.20Reactive.20Panache.20with.20a.20delay.20in.20a.20Uni/with/554127730) we figured out that you can set a custom executor to fix this:

.onItem().delayIt()
.onExecutor(ContextAwareScheduler.delegatingTo(Infrastructure.getDefaultWorkerPool()).withCurrentContext())
.by(Duration.ofSeconds(1))

Also see the docs here https://quarkus.io/guides/vertx-reference#use-a-vert-x-context-aware-scheduler

And now you can see both log statements are printed from the event loop thread:

2025-11-06 15:57:20,740 INFO  [org.acm.hib.orm.pan.FruitResource] (vert.x-eventloop-thread-2) Fruit<1>
2025-11-06 15:57:21,745 INFO  [org.acm.hib.orm.pan.FruitResource] (vert.x-eventloop-thread-2) Fruit<1>

This can be very confusing for users while programming, as it happens quite unexpectedly.

Could we somehow make Quarkus either do this automatically for us with the ContextAwareScheduler for delays? Or leverage Vertx somehow under the hood to schedule the delay with Vertx timers on the event loop?

[quarkus-bot]

You added a link to a Zulip discussion, please make sure the description of the issue is comprehensive and doesn't require accessing Zulip

_{This message is automatically generated by a bot.}

[wjglerum]

Im happy to contribute, just not sure where to get started right now.

[quarkus-bot]

/cc @cescoffier (mutiny), @jponge (mutiny)

[jponge]

Thanks @wjglerum for capturing this!

It is a good point to reconsider how we delay some tasks (e.g, an item, a retry with exponential backoff, etc).
When the current thread (i.e., the one from which we need to schedule a delay) is a Vert.x event-loop thread, then it would indeed make sense to use vertx.setTimer(...) rather than hop to a worker thread. This would eliminate (in most cases...) the need to capture the Vert.x context before we schedule, then ensure we re-attach to the original Vert.x context.

Implementation note: Mutiny exposes a static-scoped configuration through the Infrastructure class, where we can set various thing including a ScheduledExecutorService.
The operators that need an executor will reach out to Infrastructure to know which one to use, unless an executor is explicitly passed like in your example above.

There are different approaches to do this.

1. We could modify Mutiny itself to provide hooks for delayed executions, but this somehow does clash with Infrastructure already exposing configuration for a ScheduledExecutorService. Also Mutiny itself doesn't know about Vert.x, it's a generic reactive programming library.
2. We could provide a smarter ScheduledExecutorService in/to the Quarkus Mutiny extension, so all the scheduling actions first check if we are on a Vert.x event-loop, then decide what is the good strategy between a Vert.x timer and a regular ScheduledExecutorService scheduling call (e.g., to a delegating executor).

The relevant points in the Quarkus Mutiny extensions are https://github.com/quarkusio/quarkus/blob/main/extensions/mutiny/deployment/src/main/java/io/quarkus/mutiny/deployment/MutinyProcessor.java and https://github.com/quarkusio/quarkus/blob/main/extensions/mutiny/runtime/src/main/java/io/quarkus/mutiny/runtime/MutinyInfrastructure.java

It is important to note that the Mutiny extension does not depend on the Vert.x extension, so this would need to be refactored and with a word of caution: Vert.x is not guaranteed to be present (e.g., CLIs), so it's not just a straight dependency.

What we might want to do is not changing the Mutiny extension itself, but act on the ExecutorBuildItem that's being passed at https://github.com/quarkusio/quarkus/blob/main/extensions/mutiny/deployment/src/main/java/io/quarkus/mutiny/deployment/MutinyProcessor.java#L19C29-L19C46

It might actually be relevant to generalize such a "smarter" executor outside Mutiny pipelines. Since this is the worker executor in Quarkus, it might as well be the one that checks if it is being called on a Vert.x event-loop, and adapt its strategy accordingly.

Last but not least, and whatever the strategy, there is a good chance that some code breaks due to changing that Quarkus scheduling strategy (albeit, for the better).

[jponge]

/cc a bunch of folks from the initial Zulip discussion @FroMage @geoand @tsegismont @mkouba @Sanne @DavideD @yrodiere

[FroMage]

I would start with changing MutinyInfrastructure.configureMutinyInfrastructure to pass a proxy to Infrastructure.setDefaultExecutor where the relevant schedule methods are overridden to look at the current thread and delegate to Vert.x timers.

This way, this is only used by Mutiny, hopefully only for delay :)

[jponge]

There are multiple operators, not just delay 😉 (e.g., retry, etc)

[wjglerum]

@jponge thank you for your elaborate reply! Turns out I was actually looking in the right place, so thanks again for providing those pointers. Will dive into that a bit further.

Last but not least, and whatever the strategy, there is a good chance that some code breaks due to changing that Quarkus scheduling strategy (albeit, for the better).

That will probably happen yes 🤐

[jponge]

I've started exploring something here: https://github.com/jponge/quarkus/tree/scratchpad/50918-mutiny-vertx-timers-dispatch

I'm not 100% sure yet, and perhaps Mutiny should have an executor override method that doesn't try to shut the previous executor down. But it's a start, and tests seem to reflect that Uni.onItem().delayIt() and Multi.createFrom().ticks() do dispatch on a Vert.x event-loop if and only if the subscription was made from an event-loop.

[FroMage]

This looks pretty nice!