[bpamiri]

PR3 (final) of the staged #4194 route-state-helper migration. Builds on the shared $snapshotRoutes() / $restoreRoutes() / $clearRoutes() helpers (#4202) and the mapper-area migration (#4203), both on develop.

What

Migrates the remaining leak-class specs onto the shared helpers:

• dispatch/findMatchingRouteMegaSpec
• global/urlforSpec
• security/PaginationXssSpec

Each replaces hand-rolled route save/restore with $snapshotRoutes() / $restoreRoutes() and drops its local $clearRoutes shim (now inherited from wheels.WheelsTest).

Why

These were the last specs on the partial-clear list — each restored only a subset of route state (dropping namedRoutePositions and/or staticRoutes), the #4192 leak class. With these migrated, every route-manipulating spec in the suite uses the full-state helper, so none leaks stale routes into later specs.

Verification

Local (SQLite), Lucee 7 and BoxLang, all scopes 0 fail / 0 error:

• wheels.tests.specs.dispatch (27 bundles) — 261 pass
• wheels.tests.specs.global (41 bundles) — 321 pass
• wheels.tests.specs.security (36 bundles) — 403 pass
• wheelstest.SnapshotRoutesSpec — 2 pass
• internal.RequireRepoPathSpec (WHEELS_EXPECT_REPO=true, env test exercised) — 4 pass

Full cross-engine matrix dispatched separately.

Closes #4194

🤖 Generated with Claude Code

[bpamiri]

rev1-r3 review @ df1101a: APPROVE (stacked on #4203; merge after it, once matrix 37129072791 is green)

The three remaining specs are migrated mechanically:

• dispatch/findMatchingRouteMegaSpec drops its partial $clearRoutes() shim (which never cleared namedRoutePositions) and uses snapshot and restore.
• global/urlforSpec does the same and keeps its separate URLRewriting and obfuscateUrls saves.
• security/PaginationXssSpec used to save and restore only routes and namedRoutePositions. Its staticRoutes leak is now covered by the snapshot, and its $clearRoutes() call resolves to the inherited full helper.

With #4202, #4203 and #4204 together, git grep 'function $clearRoutes' under vendor/wheels/tests finds no spec-level overrides left. Only the base helper remains (plus #4192's spec, deferred until it lands).

[github-actions]

Wheels Test Results

220 807 tests   216 087 ✅  1h 20m 56s ⏱️
 17 056 suites    4 720 💤
     32 files          0 ❌

Results for commit 8a886a8.

♻️ This comment has been updated with latest results.

[bpamiri]

rev1-r3 review @ 8a886a8: code APPROVE (final sign-off after matrix run 37277585624 and PR CI)

This moves the last three specs with their own route-state code onto the shared helpers: 3 files, +14/−29, and each local $clearRoutes() is deleted.

• findMatchingRouteMegaSpec. beforeAll/afterAll now snapshot and restore everything. The old per-bundle restore covered only routes, staticRoutes and namedRoutePositions. Its local $clearRoutes() didn't reset namedRoutePositions at all, and the shared one does.
• PaginationXssSpec. This fixes the leak itself. The old code restored only routes and namedRoutePositions, so the staticRoutes its $clearRoutes() emptied was never put back.
• urlforSpec. It now snapshots and restores everything, alongside the URLRewriting / obfuscateUrls restores it keeps.

Should the urlForCache fix live in the shared helper? No, I'd keep it in the spec.

• What happened. $restoreRoutes() restores exactly: a managed key that was absent at snapshot time is deleted. That's the right behaviour, because every framework read of the app-scope urlForCache is guarded and creates it lazily (routing.cfm L529–532, Mapper.cfc L267, the reload path at L456). So deleting it puts the app back in a real state: no URL generated yet.
• The spec is order-dependent. What broke is the issue-2955 case "memo lives in application scope". It asserts StructKeyExists(application.wheels, "urlForCache") before its first urlFor() call. That only passed because an earlier spec had already created the cache, so it's an order dependence in that one test, not something the helper gets wrong.
• No other spec hits it. I grepped every spec for urlForCache. The only other app-scope users (linkToUrlForDifferentialSpec) guard with StructKeyExists before clearing, and initializeRequestScopeSpec checks the request-scope cache that $initializeRequestScope() itself creates.
• Moving it into the helper (for example "never delete urlForCache, only restore its contents") would make every spec quietly depend on that cache existing, and would hide the next order-dependent assertion instead of exposing it.

Optional, not blocking: the guard sits in the outer beforeEach, so it runs for every urlforSpec case. Moving it into the issue-2955 describe's beforeEach, or making that test assert after the first urlFor(), would keep it next to the one test that needs it. Fine as is.

[bpamiri]

rev1-r3 review @ 8a886a8: APPROVE (final; matrix run 37277585624 read leg by leg, PR CI checked)

• Matrix run 37277585624 is on this head, and all 32 legs plus rustcfml succeeded. From the junit artifact for each leg:
  • 6896–6913 tests per leg, with 0 failures and 0 errors on every leg.
  • All three migrated specs ran and passed on every leg, none skipped, including all six Adobe 2023 and all six Adobe 2025 legs and BoxLang: findMatchingRouteMegaSpec 12, urlforSpec 14 (including the issue-2955 cache cases) and PaginationXssSpec 14.
• PR CI on this head: 18 pass, 3 skipped, 0 failing or pending, including Lucee 7 + SQLite (LuCLI) (run 37277536243).