From 45e7cd564bcea94a5f63b4c89ebeef7b84c2f376 Mon Sep 17 00:00:00 2001
From: Jason Lee <56489493+jason931225@users.noreply.github.com>
Date: Wed, 19 Aug 2026 03:21:53 -0400
Subject: [PATCH] test(auth): stop starting the real-clock rate-limit test near
 a window edge

`otp_redeem_rate_limit_wires_up_on_real_clock_path` drives ten requests
expecting 401 and asserts the eleventh is 429. The limiter buckets into a
FIXED one-minute TUMBLING window -- `floor_to_window` in
crates/platform/auth-rest/src/lib.rs floors to `unix - unix.rem_euclid(60)`
-- not a sliding one, so all eleven must land inside the SAME window. When
the loop straddles a minute boundary the counter resets mid-loop and the
eleventh request is the new window's first, returning 401:

  assertion `left == right` failed: the trusted ingress identity must
  select the first per-IP bucket

Each of the eleven round-trips to PostgreSQL, so on a loaded runner the
test occupies a real fraction of the window and fails whenever it starts
late in one. It did exactly that on run 32225725163, failing #802 -- a
pull request that changes nothing near auth -- and blocking it behind an
unrelated red.

The sibling named in this test's own doc comment,
`rate_limit_trips_at_cap_and_resets_after_window`, drives `now` directly
and has no such exposure. This one exists to prove the REAL clock path is
wired, so it cannot inject a clock -- but it can decline to start near a
boundary. It now waits for a fresh window when fewer than 30 seconds
remain in the current one.

The assertion itself is unchanged: this removes a timing dependency the
test never meant to have, not a behaviour it meant to check.

Verified: cargo check -p console-app --tests, cargo fmt --check and cargo
clippy --tests all clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 backend/app/tests/auth_rest.rs | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/backend/app/tests/auth_rest.rs b/backend/app/tests/auth_rest.rs
index 11139c136..115a1a86f 100644
--- a/backend/app/tests/auth_rest.rs
+++ b/backend/app/tests/auth_rest.rs
@@ -1566,6 +1566,32 @@ async fn otp_redeem_rate_limit_wires_up_on_real_clock_path(pool: PgPool) {
         .unwrap(),
     );
 
+    // The limiter buckets into a FIXED one-minute TUMBLING window -- see
+    // `floor_to_window` in crates/platform/auth-rest/src/lib.rs, which floors to
+    // `unix - unix.rem_euclid(60)` -- not a sliding one. Every request below
+    // must therefore land inside the SAME window: if the loop straddles a minute
+    // boundary the counter resets mid-loop and the eleventh request comes back
+    // 401 instead of 429.
+    //
+    // That is not hypothetical. This test drives eleven real DB-backed requests,
+    // so on a loaded runner it occupies a meaningful fraction of the window and
+    // fails whenever it starts late in one. It did exactly that on run
+    // 32225725163, on a pull request that changed nothing near auth.
+    //
+    // The sibling test named in this test's own doc comment
+    // (`rate_limit_trips_at_cap_and_resets_after_window`) drives `now` directly
+    // and so has no such exposure; this one exists to prove the REAL clock path
+    // is wired, so it cannot inject a clock -- but it can decline to start near
+    // a boundary.
+    let into_window = OffsetDateTime::now_utc().unix_timestamp().rem_euclid(60);
+    const WINDOW_SECS: i64 = 60;
+    // Budget generously: the eleven requests each round-trip to PostgreSQL.
+    const NEEDED_SECS: i64 = 30;
+    if into_window > WINDOW_SECS - NEEDED_SECS {
+        let wait = (WINDOW_SECS - into_window + 1) as u64;
+        tokio::time::sleep(std::time::Duration::from_secs(wait)).await;
+    }
+
     // Drive the real ingress boundary: the XFF identity is accepted only from
     // the configured trusted transport peer. The first identity exhausts its
     // own bucket while the second remains independently usable.