Matej Novotny

> Got around the leak by changing the fallback to a CDI decorator @manofthepeace what do you mean by this? How does a decorator workaround this? Also, did you look...

I'll assign to myself, unless someone beats me to it, I will take a closer look tomorrow.

> I had to debug the bean discovery process to figure out why does MyJob even become a bean -- it turns out we [treat](https://github.com/quarkusio/quarkus/blob/main/extensions/smallrye-fault-tolerance/deployment/src/main/java/io/quarkus/smallrye/faulttolerance/deployment/SmallRyeFaultToleranceProcessor.java#L159) fault tolerance annotations as bean...

> Hm, I don't think this is related to SR FT `Fallback` but more likely to the Quartz integration in Quarkus, more specifically to the `JobFactory` and the way a...

> The problem in this particular setup is that the user creates a bunch of "one-off" jobs, i.e. jobs that are only executed once, not periodically based on interval/cron (which...

> > I was assuming you'd want a new one as well (as per nature of this scope). > > This is not how `org.quartz.spi.JobFactory` works. In other words, in...

It seems like `AbstractResteasyReactiveContext#requireCDIRequestScope()` completely omits the case where you already have active req. context that you didn't start up yourself and instead always tries to enforce new, blank instance...

> lgtm, but tests will be needed. I can prepare them. That would be awesome, thank you. I didn't mean to propose this as a final fix, just what I...

> It's definitely possible to use the existing request scoped state if it exists, but is that really something we want to do in all cases? Can you think of...

> What I think can become problematic is how we handle the end of the request processing in Quarkus REST. > > Currently as we always start the context, we...