Reactive RESTEasy and Hibernate Panache: Does request‑scoped context survive worker offload?

Short answer

No — not by default. When a reactive RESTEasy resource returns a Uni or Multi and Quarkus off-loads a blocking Hibernate Panache call to a worker thread, the CDI request context and Vert.x thread-local data do not automatically travel with it. The repository method will typically see an inactive request context (or a default/null security identity) and MDC values set on the event-loop thread are lost. The standard fix is the SmallRye Context Propagation extension, which is designed exactly for this boundary.

What is established vs. what is assumed

Established behavior (well-documented Quarkus design):

• Blocking work (including classic Hibernate ORM with Panache) must not run on the Vert.x event loop, so Quarkus moves it to a worker thread.
• Thread-local state — including the CDI request context and SLF4J/Logback MDC — is bound to the original thread and is not copied automatically.
• Quarkus integrates with MicroProfile Context Propagation via the quarkus-smallrye-context-propagation extension. With it on the classpath, context is captured when a Uni/Multi pipeline is assembled and restored around each stage, including stages that execute on worker threads.

Assumptions to verify in your setup:

• Exact behavior (which contexts are propagated, and whether activation of the request context on the worker thread is automatic) depends on your Quarkus version. This was written against the Quarkus 3.x line; check the context-propagation guide for your exact version.
• If you use Hibernate Reactive with Panache instead of blocking Panache, there is no worker off-load at all — the session runs on the event loop and this problem does not apply.

Steps for this case

1. Add the extension:

   ./mvnw quarkus:add-extension -Dextensions="smallrye-context-propagation"

2. In the resource, make sure the blocking Panache call happens inside the Uni pipeline rather than before it, so the captured context is restored when the stage executes:

   @GET
   public Uni<List<Item>> items() {
       return Uni.createFrom().item(() -> itemRepo.findForCurrentUser());
   }

3. Verify: log the injected SecurityIdentity principal and an MDC key inside the repository method. With the extension present they should match the values set during request processing; temporarily removing the extension should show them missing — a quick A/B check that confirms propagation is what fixed it.

Vert.x thread-locals and manual capture

There is no separate switch to make raw Vert.x thread-local storage flow with Uni/Multi continuations; the context-propagation extension is the mechanism Quarkus provides, and it covers CDI scopes plus MDC. Manual capture-and-restore (reading the principal/MDC on the request thread, closing over the values, and re-applying them in the blocking stage) works but is fragile: it is easy to miss a path, and it leaks request data if you forget to clear it on the worker thread. Treat it as a fallback, not a pattern.

Open point

One detail would change this recommendation: are you on blocking Panache (this answer applies) or Hibernate Reactive Panache (no off-load, different context rules)? Also confirm your Quarkus version, since propagation defaults have evolved across releases.