fix: bump windows for analytics tests

Author: nams1570

apps/e2e/tests/backend/endpoints/api/v1/analytics-events-batch.test.ts

@@ -528,8 +528,17 @@ it("accepts batch and debits event quota correctly", async ({ expect }) => {
   const { ownerTeamId } = await setupProjectWithPlan("free");
   await Auth.Otp.signIn();
 
-  // Drain async logEvent debits (sign-in triggers token-refresh/sign-up-rule events asynchronously) before measuring baseline.
-  const quantityBeforeBatch = await waitForItemQuantityToStabilize(ownerTeamId, ITEM_IDS.analyticsEvents);
+  // Drain async logEvent debits (sign-in triggers token-refresh/sign-up-rule
+  // events asynchronously) before measuring baseline. The
+  // `minimumElapsedMs` guards against the failure mode where stability is
+  // declared before the async events have had a chance to fire — without
+  // it the test reads e.g. 100000, declares it stable, then ~5s later the
+  // async events land and the post-batch read is short by 2.
+  const quantityBeforeBatch = await waitForItemQuantityToStabilize(
+    ownerTeamId,
+    ITEM_IDS.analyticsEvents,
+    { minimumElapsedMs: 5000 },
+  );
 
   const now = Date.now();
   const eventCount = 3;
@@ -561,7 +570,13 @@ it("rejects batch when remaining quota is less than batch size and does not debi
   // Drain async logEvent debits before forcing the quota down to a known
   // value — otherwise a trailing in-flight debit would push it negative
   // after we set it to 2 and break the post-condition.
-  await waitForItemQuantityToStabilize(ownerTeamId, ITEM_IDS.analyticsEvents);
+  // `minimumElapsedMs` guards against returning before the async events
+  // have started firing.
+  await waitForItemQuantityToStabilize(
+    ownerTeamId,
+    ITEM_IDS.analyticsEvents,
+    { minimumElapsedMs: 5000 },
+  );
   await setItemQuantity(ownerTeamId, ITEM_IDS.analyticsEvents, 2);
 
   const res = await uploadEventBatch({

apps/e2e/tests/backend/endpoints/api/v1/analytics-events.test.ts

@@ -60,12 +60,25 @@ const queryEventDataJson = async (params: {
   },
 });
 
+// Defaults give 40 attempts * 500ms = ~20s of polling.
+//
+// The events under test are produced *asynchronously* by the sign-in path:
+// `runAsynchronouslyAndWaitUntil(logEvent)` fires after the HTTP response
+// returns and runs through SDK self-call → quota debit → Postgres insert →
+// ClickHouse async_insert (which is server-buffered, no wait_for_async_insert).
+// Under CI load this whole pipeline can take well over 10s before the row
+// becomes queryable, so the previous 7.5s window was still flaking with
+// "expected 0 to be greater than 0". 20s is conservative; the loop breaks
+// out as soon as the row appears, so there's no cost on the happy path.
+const DEFAULT_QUERY_RETRY_ATTEMPTS = 40;
+const DEFAULT_QUERY_RETRY_DELAY_MS = 500;
+
 const fetchEventDataJsonWithRetry = async (
   params: { userId?: string, eventType?: string },
   options: { attempts?: number, delayMs?: number } = {}
 ) => {
-  const attempts = options.attempts ?? 5;
-  const delayMs = options.delayMs ?? 250;
+  const attempts = options.attempts ?? DEFAULT_QUERY_RETRY_ATTEMPTS;
+  const delayMs = options.delayMs ?? DEFAULT_QUERY_RETRY_DELAY_MS;
 
   let response = await queryEventDataJson(params);
   for (let attempt = 0; attempt < attempts; attempt++) {
@@ -87,8 +100,8 @@ const fetchEventsWithRetry = async (
   params: { userId?: string, eventType?: string },
   options: { attempts?: number, delayMs?: number } = {}
 ) => {
-  const attempts = options.attempts ?? 5;
-  const delayMs = options.delayMs ?? 250;
+  const attempts = options.attempts ?? DEFAULT_QUERY_RETRY_ATTEMPTS;
+  const delayMs = options.delayMs ?? DEFAULT_QUERY_RETRY_DELAY_MS;
 
   let response = await queryEvents(params);
   for (let attempt = 0; attempt < attempts; attempt++) {

apps/e2e/tests/backend/endpoints/api/v1/auth/sessions/current/refresh-race.test.ts

@@ -45,7 +45,11 @@ it("does not 500 when a refresh races with a sign-out of the same session", { ti
       mailbox: createMailbox(`refresh-race--${randomUUID()}${generatedEmailSuffix}`),
       userAuth: null,
     });
-    await Auth.Password.signUpWithEmail();
+    // `noWaitForEmail`: the race test only needs a refresh token, which is
+    // returned by the sign-up response itself. Waiting for the verification
+    // email costs 5–10s per iteration on CI and pushes the test past its
+    // 120s timeout.
+    await Auth.Password.signUpWithEmail({ noWaitForEmail: true });
     const rt = backendContext.value.userAuth!.refreshToken!;
 
     const refreshP = niceBackendFetch("/api/v1/auth/sessions/current/refresh", {
@@ -84,7 +88,8 @@ it("does not 500 when an OAuth refresh-token grant races with a sign-out of the
       mailbox: createMailbox(`oauth-refresh-race--${randomUUID()}${generatedEmailSuffix}`),
       userAuth: null,
     });
-    await Auth.Password.signUpWithEmail();
+    // See note above on `noWaitForEmail`.
+    await Auth.Password.signUpWithEmail({ noWaitForEmail: true });
     const rt = backendContext.value.userAuth!.refreshToken!;
     const projectKeys = backendContext.value.projectKeys;
     if (projectKeys === "no-project") throw new Error("No project keys found in the backend context");

apps/e2e/tests/backend/payment-quota-helpers.ts

@@ -76,37 +76,45 @@ export async function waitForItemQuantityToReach(
 }
 
 /**
- * Polls the item quantity every 500ms until it stops changing for 8 reads
- * in a row (~4 seconds of no movement), then returns the stable value.
- * Throws if no stable value is observed within 15 seconds.
+ * Polls the item quantity every 500ms until it stops changing for
+ * `stableForReads` reads in a row, then returns the stable value. Throws
+ * if no stable value is observed within `timeoutMs`.
  *
  * Use this when you DON'T know the exact target — for example, after
  * `Auth.Otp.signIn()` triggers an unknown number of async logEvent debits
  * (token-refresh + sign-up-rule events) and you just want them to drain
  * before measuring a baseline.
  *
- * The 4-second stability window is deliberately conservative: a shorter
- * one (we tried 1.2s) exits during brief lulls between batches of late-
- * arriving sign-up-rule debits and lets ~2 extra debits land between the
- * baseline read and the next test request, breaking exact-quota
- * assertions.
+ *
+ * `options.minimumElapsedMs` (default 0) refuses to return until at least
+ * that much wall time has passed since the function was called, even if
+ * the quantity has been stable the whole time. This is useful when the
+ * caller knows async events should fire but hasn't seen them yet — it
+ * prevents the function from declaring stability before the async work
+ * has even started.
  */
 export async function waitForItemQuantityToStabilize(
   ownerTeamId: string,
   itemId: ItemId,
+  options: { minimumElapsedMs?: number } = {},
 ): Promise<number> {
   const pollIntervalMs = 500;
-  const stableForReads = 8;
-  const timeoutMs = 15000;
+  const stableForReads = 16;
+  const timeoutMs = 30000;
+  const minimumElapsedMs = options.minimumElapsedMs ?? 0;
   const startedAt = performance.now();
 
   let last = await getItemQuantity(ownerTeamId, itemId);
   let stableReads = 1;
 
-  while (stableReads < stableForReads) {
-    if (performance.now() - startedAt > timeoutMs) {
+  while (true) {
+    const elapsed = performance.now() - startedAt;
+    if (stableReads >= stableForReads && elapsed >= minimumElapsedMs) {
+      return last;
+    }
+    if (elapsed > timeoutMs) {
       throw new StackAssertionError(`Item quantity did not stabilise within timeout`, {
-        ownerTeamId, itemId, last, stableReads, stableForReads, timeoutMs,
+        ownerTeamId, itemId, last, stableReads, stableForReads, timeoutMs, minimumElapsedMs,
       });
     }
 
@@ -120,6 +128,4 @@ export async function waitForItemQuantityToStabilize(
       last = next;
     }
   }
-
-  return last;
 }