https://krzysztofslusarski.github.io/2022/12/12/async-manual.html#context-id shows what's currently possible (and in the future with JFR with https://bugs.openjdk.org/browse/JDK-8284453) if you have a profiler able to collect traces per externally provided "context ID" i.e. performing a very lightweight distributed continuous profiling which collect and present data in a very easy consumable format e.g. flamegraphs and/or JFR events.

A Concrete implementation would produce a flamegraph like this:
https://krzysztofslusarski.github.io/assets/async-demos/context-1.html

This is a flamegraph which base stack is a single app.
The total flamegraph data contains 3 different apps: first/second/thidApp
The stack trace here is a "real" one because the example from the blog post wasn't caring about the reactive stack.
However, if we provide a context id that's used by the same processing pipeline of smallrye, for each of its stages we can collect them in 2 ways:

• Base stack context ID of the N stages and all the stages under the same context ID (unordered but coherent - belonging to the same context id).
• If we provide additionally number for the stages, in sequence eg context ID = 2, smallrye stage = 1,2,3,4 we might show the stages in the right temporal sequence... To be confirmed because AFAIK smallrye probably can execute stages in parallel - meaning that order is partial.

This would allow us to report all the pieces of processing of a reactive request under the same context ID, because right now they all mix (they are unrelated to each others) while collected on the same thread.