chore(flags): wait for the test server in rate-limit tests

[posthog]

Problem

• test_rate_limit_replenishment was quarantined again on 2026-09-07, so the /flags rate-limit guard no longer blocks a regression in CI.
• The test posts to /flags right after ServerHandle::for_config_*, which starts the server in tokio::spawn. No test in this file waits for the server.
• When startup fails inside that task (a dependency the runner cannot reach, a missing local asset), serve returns early and drops the listener. The first request then fails with a bare transport error and no assertion text — which is what the Trunk event for this test shows.
• The previous fix (65ab79a) removed real-time sleeps with a fake clock. Timing is now deterministic, so startup is the remaining source of failure.

Changes

• Every test in rust/feature-flags/tests/test_rate_limiting.rs calls server.wait_until_ready().await before its first request. The helper already existed and is used by four other test files.
• A startup failure now reports Server failed to become ready within 5 seconds instead of a transport error, so the next flake names its own cause.
• All 20 tests in the file get the line, not only the quarantined one. They share the same race and the same silent failure mode.
• The readiness route sits outside the rate-limited router, so the extra request consumes no token or IP bucket capacity. Rate-limit assertions are unchanged.

How did you test this code?

Automated only. No manual product testing applies to a test-only change.

• cargo test -p feature-flags --test test_rate_limiting — 20 passed.
• cargo test -p feature-flags --test test_rate_limiting test_rate_limit_replenishment — 8 consecutive runs, all passed.
• No new test was added. The change makes an existing regression guard trustworthy again.

Failure-mode comparison, forced by removing a local startup asset

Server init fails in both runs. The difference is what the test reports.

Branch	Reported failure
master	client error (SendRequest) → connection error → Connection reset by peer (os error 104)
this PR	Server failed to become ready within 5 seconds

Not checked: whether Trunk clears the quarantine. That needs several green runs on master after this lands.

Automatic notifications

• Publish to changelog?

Docs update

None. The change touches test code only.

🤖 Agent context

Autonomy: Fully autonomous

• Written by Claude Opus in PostHog Desktop, from an inbox report about the quarantined test. No repo skill applied to a Rust test-only diff.
• No duplicate: gh pr list --state open --search for test_rate_limiting and for the flaky test name returned nothing.
• Considered and rejected: keeping the fix to the one quarantined test. The other 19 tests build the server the same way, so a partial fix leaves the same trap for the next report.
• Also examined the rate-limiter cleanup task and the governor fake-clock arithmetic as alternative causes. Both are deterministic here, so neither explains a flake after the clock fix.
• The startup failure mode was confirmed locally by removing a startup asset and running the test with and without the change, not inferred from a CI log — the Trunk event carries no error text.
• Public artifact: nothing in this PR comes from the session beyond what the repository and the linked report already hold.

---

Created with PostHog Desktop from this inbox report.

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[posthog]

🦔 PostHog Review reviewed this pull request

Nothing worth raising this time, so here's a calming picture instead:

[github-actions]

🤖 CI report

✅ Trunk lane — non-backend lane

This PR is assigned to the non-backend lane. It does not run backend Python tests and may merge in parallel with PRs in other lanes.

[stamphog]

Approved.

Test-only, additive change: adds an existing readiness-wait helper before the first request in 20 rate-limit tests, matching the description exactly. No risky territory touched, no outstanding comments or in-flight reviews.

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	0L, 0F substantive, 20L/1F incl. docs/generated/snapshots — within ceiling
tier	✓	T0 auto-approve: T0-deterministic (20L, 1F, single-area, chore)
stamphog 2.0.0b4		.stamphog/policy.yml @ 124c132 · reviewed head 124c132

[trunk-io]

   

View Full Report ↗︎ ⋅ Docs