The GitHub Actions job "Groovy Snapshot Canary Build" on grails-core.git/perf/request-path-8.0.x has succeeded. Run started by GitHub user codeconsole (triggered by codeconsole).
Head commit for run: 0e0d5993be88547224090981d97b75f995663e7a / Scott Murphy Heiberg <[email protected]> fix: give every Grails-level reader the method the request routed as Review pointed out that only some of what reads the request method saw the override, and it was right: the rule had never been decided, only arrived at. Three readers still answered with the POST on the wire, which meant the same application behaved differently depending on whether the override came from the servlet filter or from the dispatcher - the one thing moving it was supposed not to change. A method-keyed name in a URL mapping - "action = [GET: 'list', PUT: 'save']" - picked the POST entry, so a form that routed as PUT reached the wrong action. Link generation defaulted to the request's method when the caller named none, so a link built during an overridden request reverse-mapped against POST mappings. A renderer asking RenderContext for the method it was answering was told POST. All three now read HiddenHttpMethod.effectiveMethod, which is the request's own method wherever a filter did the rewriting, so both modes agree. The rule this settles, now written into the upgrade note as a table: what Grails resolves from the request - mapping resolution, allowedMethods, link generation, RenderContext - answers with the overridden method; the servlet request and therefore everything outside Grails answers with the method on the wire. Command object initialization is the one reader left on the wire method. Its branch only diverges for a domain-class command object reached without an id, which needs a GORM-backed controller harness to exercise, and an untested change to how command objects are instantiated is not worth carrying here. Report URL: https://github.com/apache/grails-core/actions/runs/33427840013 With regards, GitHub Actions via GitBox
