Replay format and dotted route examples and record claims

Tomasz Skoruparequested to merge
tskorupa/731-snapshot-adversarial-examples-and-claims into main

What does this MR do and why?

This MR replays route examples from a snapshot JSON downloaded from gitlab-org/gitlab, and for each match records the claim that match would send to Topology Service.

The old snapshot carried only a plain "foo"-style example per route, which hid two bug classes:

  1. Format-suffixed static routes like /users/sign_in.json can misroute to a claim-extraction rule instead of the static rule.
  2. Dotted parameter values like john.doe can have their claim cut at the wrong dot.

The snapshot format changed upstream in gitlab-org/gitlab!252764 (merged), so this MR was updated to match. Each row now carries template, example, an optional acceptsFormat: true boolean (the route accepts an optional .:format suffix), and an optional dottedExample string (an example built with dotted parameter values such as john.doe). A small examplesOf test helper composes the URL variants itself: example, example + ".json" when acceptsFormat is set, dottedExample when present, and dottedExample + ".json" when both apply. So up to four URLs per row are still replayed, but the .json variants are no longer materialized in the snapshot, which keeps the snapshot file much smaller.

The snapshot in this MR was re-downloaded from current master and now has 4449 routes. src/generated_route_guards.ts is unchanged; regenerating it from the new snapshot produced no diff.

Note for reviewers: most of the diff is the regenerated vitest snapshot and the downloaded routes JSON. The actual logic changes are in test/routes/routes.spec.ts, test/routes/matcher.ts (getMatchedRoute now also returns params), test/routes/gitlab_routes.ts (validates the new optional fields), and a claimParsers export in src/handlers/claim_path_handler.ts.

This MR previously included its own snapshot-fetch script, which was superseded by the merged !1293 (merged) ("Download GitLab's routing snapshot instead of generating it"). What remains here is a single commit on top of main.

References

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Tomasz Skorupa

Merge request reports