Maciej Gromuł

In general it seems it's impossible to make "seamless" tracing with flux publishers (whether it's reactor kafka or other flux source) since the context is bound with publisher as whole,...

Yes sorry, it should be downstream (got the naming mixed up midway, i've updated the issue description). The problem with attaching observation to each single mono is that we can't...

If we are to assume that metrics and observations in the end will produce different set of metrics by design then it should be added in [metrics.adoc](https://github.com/reactor/reactor-core/blob/main/docs/asciidoc/metrics.adoc). Right now the...

> @Gromcio I wrote a [three-part blog post series about this subject](https://spring.io/blog/2023/03/28/context-propagation-with-project-reactor-1-the-basics) if you're keen to understand more. In a nutshell, the approach Spring Cloud Sleuth took is not ideal...

I don't believe we can even get the metrics correctly with unbounded flux and tap operator in current state as they are depending on onFirst/onComplete "events". Event if we tried...

>In that regard, tracking latency across scheduler boundaries isn't really an issue, because we probably want to include that time in the latency being measured. Totally agree, if it's to...

> I can see how you could come to that conclusion by taking a look at the [AloContext source code](https://github.com/atleon/atleon/blob/3d309c4e965ad2fe4f24700e2795b9d1bd5e6617/core/src/main/java/io/atleon/context/AloContext.java), but this is fortunately not true. Only access to the...

> You don't need a "new" CUSTOM_KEY generated for each element I think I misunderstand something here. CUSTOM_KEY is a type of Key that generally has just a string with...