Propagate context to message converters when streaming with Flux in Spring MVC

[dsyer]

#32296 and #32112 are now closed but the sample that I was interested in is still broken (see link in the latter): the RequestContextHolder is still empty in an HttpMessageConverter being used to render a Flux as a MediaType.TEXT_EVENT_STREAM.

[rstoyanchev]

Those are related issues but not the same. It means after the changes, the following works:

@GetMapping(path = "/", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<Greeting> stream() {
	return Flux.interval(Duration.ofSeconds(1))
			.doOnNext(o -> {
				RequestAttributes attributes = RequestContextHolder.getRequestAttributes();
				System.out.println("RequestAttributes: " + attributes);
			})
			.map(value -> new Greeting("bar"));
}

When Spring MVC subscribes to the Flux, it uses Micrometer Context Propagation to capture ThreadLocals it knows about, and inserts those into the Reactor Context where they can be accessed as key-value pairs. In addition, Reactor supports restoring ThreadLocals in the Flux chain, which is why doOnNext above finds the request.

The HttpMessageConverter, however, is called from the subscriber to the Flux, and it's not covered by the above, and message converters generally don't depend on thread local context.

[dsyer]

I'm not sure I follow yet - isn't the subscriber Spring MVC, which you said would propagate the context? By "works" you mean "prints out request attributes", I guess, but that's not helpful if the HttpMessageConverter cannot access the thread local context. What I really want to do is render a View in the message converter, so I'm going to need the web context. Is there another way? Can we make it work somehow without leaking thread context - I don't think users (i.e. me) should be trusted to get that right without help from the framework?

[rstoyanchev]

@dsyer this should work now. Please, give it another try.