The GitHub Actions job "SiteMesh 2 Compatibility" on grails-core.git/revert/16192-async-changes has succeeded. Run started by GitHub user jdaugherty (triggered by jdaugherty).
Head commit for run: bc41fa9274c0eea4aaab09c1c30cda579c83d14e / James Daugherty <[email protected]> Require a cycle the decorator started to still be running The decorator fix taken from #16226 loosened the guard on running a task from request.isAsyncStarted() to !asyncRequest.isAsyncComplete(), for every task. The loosening is what lets a task join a cycle the container is delivering -- isAsyncStarted() is already false in that window although the request is still live -- but applying it to the path that starts its own cycle widened when those tasks run: between dispatch() or complete() and the container's onComplete, a task that would previously have refused now binds a request the container may be recycling. The guard is now split by how the decorator got its cycle, recorded at construction. A cycle started here must still be running, exactly as before; a joined cycle is exempt for the delivery window joining exists for. The completion check also moves ahead of touching the AsyncContext, whose getRequest() throws its own message once the cycle has completed. A task can still lose its cycle between the guard and the closure body -- that race predates all of this and cannot be closed from here; the guard's job is only not to widen it. AsyncWebRequestPromiseDecoratorSpec pins all four corners: started-and-running runs, started-and-dispatched refuses (this one fails against the single loosened guard), joined-in-delivery runs, joined-then-completed refuses. Report URL: https://github.com/apache/grails-core/actions/runs/32894903230 With regards, GitHub Actions via GitBox
