Fix and reenable SimpleContextPropagationTest.testArcMEContextPropagationDisabled

[gsmet]

It has been disabled here because it was flaky: https://github.com/quarkusio/quarkus/pull/28127 .

/cc @mkouba @FroMage

[quarkus-bot[bot]]

/cc @FroMage, @manovotn

[manovotn]

@gsmet got link to some PRs that failed this? I have been trying to reproduce this with a loop execution locally but so far not a single failure.

BTW this is the same test that we tried to fix in https://github.com/quarkusio/quarkus/pull/27284 Although back then I think I saw at least some failures locally...

[gsmet]

Yes, here for instance: https://github.com/quarkusio/quarkus/pull/28121

[manovotn]

I spent some fair tome debugging this yesterday. From my findings, I was never able to reproduce the failure when running the whole test class. However, if you run this one test directly, you can (at least mostly) get the failure.

I could see that in case of failure the CP actually behaves correctly but the problem is with the original req. context inside plain @Get method - this one doesn't get terminated at all. Now, these test use old RE Classic with undertow beneath; I am not sure if it is intended or if we could just rewrite them to use RE reactive. Note that some of the tests make use of io.reactivex.Single and io.smallrye.mutiny.Multi as the endpoint method's return value and I have no clue if this is legit in RE reactive.

Maybe @geoand would know if rewriting this to RE reactive makes sense? It'd probably be more fruitful than trying to pinpoint the failure for RE classic and undertow which are (as far as I know) deprecated anyway?

[geoand]

Yes, it makes total sense. The combination of using reactive types with RESTEasy Classic is just too problematic (and is one of the reasons why we did RR in the first place).

[gsmet]

BTW, I'm wondering if we could get rid of io.reactivex.Single now? @cescoffier WDYT?

[cescoffier]

@gsmet yes, probably time to remove the RX java 2 support

[geoand]

Definitely +1 for that