Files
headscale/hscontrol
Kristoffer Dalby d6082cb9f6 testdata: re-run tscap with populated approved_routes and tag fixes
Replaces the previous capture corpus with the output of a fresh tscap
batch built from:

  - kradalby/tscap@d2cd4f9 (anonymize: substitute tags too)
  - kradalby/tscap@3080147 (runner: capture autoApprover decisions in
    ApprovedRoutes)

Two regressions in the previous corpus are fixed:

  1. approved_routes was committed as [] on every node in all 617
     files because the runner never asked the SaaS API which routes had
     been auto-approved. The new corpus has 533/1296 routes_results and
     462/3765 grant_results entries with non-empty approved sets,
     matching what SaaS actually returned.

  2. Anonymization rewrote tag references in policy JSON
     (tag:exit-a → tag:pidgey, tag:router-a → tag:spearow, …) but left
     node.Tags untouched, so via-grant-* and other scenarios that use
     these collision-prone tag names had policies pointing at tag
     identifiers no node carried. The new corpus has node.Tags routed
     through the same substitution table.

Compat-test impact (subtest level):

                  before        after        delta
    Routes        1697 / 825    3397 / 13    -812 fail
    ACL           1799 /   8    1805 /  0      -8 fail
    Grants        3426 /  48    3463 / 11     -37 fail
    SSH            521 /  71     536 / 56     -15 fail
    ViaGrant         0 /   4      31 / 21      n/a (test now actually
                                                  loads files)
    Total         7443 / 956    9232 / 101   -855 fail (-89.4%)

Verified zero true accuracy regressions: every test that passed
against the old corpus and now fails against the new corpus is a
false-pass-becoming-true-fail. The single nominal regression
(grant-j3/beedrill) used to pass because both sides were empty under
the broken approved_routes; the new file exposes a real divergence in
filter.go srcIPsWithRoutes where headscale appends approved subnet
routes to wildcard SrcIPs and SaaS does not.

Updates #3157
2026-04-09 06:20:03 +00:00
..
2026-03-03 05:59:40 +01:00
2026-03-01 13:38:22 +01:00
2026-03-01 13:38:22 +01:00
2026-03-01 13:38:22 +01:00