Ensure tilde$1 onExit is run in correct order

[masonedmison]

Resolves #13049

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: masonedmison / name: Mason Lazalier Edmison (b2d2056, ced90a6)
• ✅ login: laurit / name: Lauri Tulmin (25eb025, d2c32be)

[masonedmison]

If you guys are happy with this, I can make a similar change to the Akka instrumentation: the same race condition exists within its RouteConcatenation.

[trask]

how hard would it be to add a test for this? thanks

[trask]

(if you rebase, we've fixed the CI failure that you're seeing)

[masonedmison]

how hard would it be to add a test for this? thanks

@trask I just played around with this for a bit and I'm having a difficult time reproducing this using straight pekko code; it might be difficult to write a failing test without introducing the tapir-pekko module as it's only with this construction of the route that the issue is triggered (at least as far I've experienced).

[laurit]

This advice will apply also when the original method threw an exception because of the onThrowable = Throwable.class. Perhaps it would be better to write this as

    public static void onExit(
        @Advice.Argument(value = 2) RequestContext ctx,
        @Advice.Return(readOnly = false) Future<RouteResult> future,
        @Advice.Thrown Throwable throwable) {
  if (throwable != null) {
    PekkoRouteHolder.restore();
  } else {
    future = future.andThen(new OnExitFinalizer(), ctx.executionContext());
  }

I don't know how scala futures work but in java CompletableFuture the methods starting with then only apply when the future completes successfully. With CompletableFuture whenComplete would be a better choice. Please check whether andThen also runs when the future does not complete normally.

[masonedmison]

andThen will be evaluated regardless of how the Future completes: the input of this supplied function to andThen takes a Try which models both success and failures, and the function we supply executes PekkoRouteHolder.restore() regardless of the input; e.g., we unconditionally restore regardless of how the Future completed. Importantly, andThen doesn't affect the return value of the Future and swallows any exceptions thrown within the supplied function. If I understand the above correctly, I believe this does what we want.

[laurit]

Thanks for confirming this.

[laurit]

how hard would it be to add a test for this? thanks

@trask I just played around with this for a bit and I'm having a difficult time reproducing this using straight pekko code; it might be difficult to write a failing test without introducing the tapir-pekko module as it's only with this construction of the route that the issue is triggered (at least as far I've experienced).

If you are reluctant to add extra dependencies you could add a separate test suite (search for registering(JvmTestSuite::class)) Suites have their own set of dependencies and are isolated from the other tests.

[masonedmison]

how hard would it be to add a test for this? thanks

@trask I just played around with this for a bit and I'm having a difficult time reproducing this using straight pekko code; it might be difficult to write a failing test without introducing the tapir-pekko module as it's only with this construction of the route that the issue is triggered (at least as far I've experienced).

If you are reluctant to add extra dependencies you could add a separate test suite (search for registering(JvmTestSuite::class)) Suites have their own set of dependencies and are isolated from the other tests.

@laurit I ended up adding the tapir-pekko-http dependency as a testImplementation. With this, I was able to write a failing test (e.g., I added the test and dropped the commit that modifies the onExit logic, and the test failed; with the commit back in place, the test passes).

[masonedmison]

@trask Do you have a sense of when this will be released?

[trask]

Second half of next week