@RequestScoped doesn't work with fault tolerance @Retry

[blsouthr]

I have two request scoped beans. One is holding request data and another is using that data in error case to include it in error response. this however doesn't work if I add Retry annotation.
See attached project with tests. Quarkus 0.26.1

getting-started.zip

1. Start project.
2. do curl http://localhost:8080/hello/error?data=hello
3. expected response should contain hello, but returns nothing
4. Delete Retry annotation from GreetingResource.helloError and all works as expected

[geoand]

@mkouba @Ladicek Is this something you are aware of ?

[mkouba]

Hello @blsouthr, the GreetingResource.helloError(String) method is executed on a different thread with a new request context. In other words, the original request context is not propagated. I'm not sure whether the MP FT spec defines this behavior though - @Ladicek WDYT?

[blsouthr]

@mkouba yes, I know. But I think it is a bug. It's working in thorntail btw

[Ladicek]

@mkouba If the GreetingResource.helloError(String) method is executed on a different thread, then there's something terribly wrong. There's no @Asynchronous and there's no @Timeout, so it must be on the same thread, unless I'm missing something.

[mkouba]

I'm not sure what the current impl does but I do think that originally (ie. first versions of SmallRye FT) the retry logic was performed within a Hystrix command that was executed on a different thread...

[Ladicek]

I think I had to rewrite how retry is handled because it didn't work properly in async scenarios. (Basically I think we handle retries manually in SmallRye FT, instead of relying on Hystrix.)

[mkouba]

Ok, would you care to take this issue @Ladicek?

[Ladicek]

So, funny thing is: the retried attempts are invoked on the request-handling thread. But the exception mapper is invoked on a different thread!

[Ladicek]

If I change the retry delay from 500 millis to 5 millis, the exception mapper is invoked on the original request-handling thread, but I'm still getting an empty response. I don't think this is a SmallRye FT problem.

[Ladicek]

I just tried adding quarkus-undertow to switch RESTEasy to Servlet, but no, that doesn't help.

[mkouba]

So it seems that the contexts are broken by smallrye-context-propagation-propagators-rxjava1 which automatically registers some context propagators for rxjava1 and Hystrix is using rxjava1 under the hood. I've also noticed that due to this propagation the ArcContextProvider is invoked continuously, even if no FT operation is called. This could represent a significant overhead.

@FroMage is it possible to disable the propagation for rxjava1 somehow? If not we should really make it possible because you can't simply exclude the smallrye-context-propagation-propagators-rxjava1 dependency.

For the record - I've tried to remove the smallrye-context-propagation dependencies from the quarkus-smallrye-fault-tolerance extension and it worked.

[mkouba]

@kenfinnigan @FroMage Why do we have smallrye-context-propagation dependencies in the quarkus-smallrye-fault-tolerance extension? It does not seem to be necessary.

[manovotn]

The PR that added it traces back to #1537