Summary
Delivery groups — the headline feature of v2.6.0 — have no acceptance-test coverage at all. Separately, the metrics acceptance tests that do exist were written around two bugs, so they could never have caught them.
1. Delivery groups: zero coverage
grep -rn "delivery-group" test/acceptance/ # → 0 hits
Nothing in the AT suite passes --delivery-group-key, --delivery-group-rate, --delivery-group-rate-period or --delivery-group-overrides, in either the standalone (gateway destination) or inline (--destination-delivery-group-*) form.
What does exist is destination-level rate limiting (--destination-rate-limit, three cases in connection_test.go:1586-1682), which is pre-existing v2.5.0 functionality, not delivery groups.
Consequence: a green acceptance run on the release PR confirms the release did not break what v2.5.0 already did. It says nothing about the feature the release is being cut for. Every delivery-group bug found so far (#393, and the two fixed in #392) was found by hand, not by CI.
Suggested cases
2. The metrics ATs encode the bugs they should have caught
test/acceptance/metrics_test.go:
Both passed before and after the fix. Worth adding the cases that would have failed: --measures pending with no granularity, and --measures queue_depth.
Why this is worth doing rather than noting
The acceptance suite is the gate the release is judged on. Where it has no coverage the gate reports green, which reads as "verified" rather than "not tested" — the same silent-success shape as the bugs themselves.
Related
Filed by Claude on Phil's behalf, from release-candidate testing.
Summary
Delivery groups — the headline feature of v2.6.0 — have no acceptance-test coverage at all. Separately, the metrics acceptance tests that do exist were written around two bugs, so they could never have caught them.
1. Delivery groups: zero coverage
Nothing in the AT suite passes
--delivery-group-key,--delivery-group-rate,--delivery-group-rate-periodor--delivery-group-overrides, in either the standalone (gateway destination) or inline (--destination-delivery-group-*) form.What does exist is destination-level rate limiting (
--destination-rate-limit, three cases inconnection_test.go:1586-1682), which is pre-existing v2.5.0 functionality, not delivery groups.Consequence: a green acceptance run on the release PR confirms the release did not break what v2.5.0 already did. It says nothing about the feature the release is being cut for. Every delivery-group bug found so far (#393, and the two fixed in #392) was found by hand, not by CI.
Suggested cases
--delivery-group-overrides, read back, assert the storeddelivery_policyupsertand assert the overrides survived — the gateway upsert silently destroys delivery_policy.groups.overrides #393 regression guard, currently covered only by a unit testconnection create/connection upsertwith the--destination-*prefixed forms--rate-limit/--delivery-group-*against--type CLIis rejected (the fix: delivery-group data loss and metrics defects, plus the missing acceptance coverage #392 fix)2. The metrics ATs encode the bugs they should have caught
test/acceptance/metrics_test.go:TestMetricsEventsPendingpasses--measures pending --granularity 1h. Granularity was exactly the workaround for the routing bug fixed in fix: delivery-group data loss and metrics defects, plus the missing acceptance coverage #392 — without it the command returned a 422. The test asserts the broken behaviour's happy path.TestMetricsEventsQueueDepthuses--measures max_depth, neverqueue_depth— the value advertised in--helpthat could never succeed.Both passed before and after the fix. Worth adding the cases that would have failed:
--measures pendingwith no granularity, and--measures queue_depth.Why this is worth doing rather than noting
The acceptance suite is the gate the release is judged on. Where it has no coverage the gate reports green, which reads as "verified" rather than "not tested" — the same silent-success shape as the bugs themselves.
Related
test-dst-*)Filed by Claude on Phil's behalf, from release-candidate testing.