From 881e31a6618f078eaad8fbb7b7b6c9b7e813e5a8 Mon Sep 17 00:00:00 2001
From: "google-labs-jules[bot]"
 <161369871+google-labs-jules[bot]@users.noreply.github.com>
Date: Tue, 24 Feb 2026 20:51:19 +0000
Subject: [PATCH] chore(ai): CI health fixes (flaky tests)

Fixed flaky test in tests/hashtag-preferences.test.mjs caused by mock timing issue where load() triggered concurrent fetches, breaking the assumption of sequential calls. Updated assertions to robustly handle multi-kind fetching.

Co-authored-by: PR0M3TH3AN <53631862+PR0M3TH3AN@users.noreply.github.com>
---
 ...2-24_20-46-12_ci-health-agent_completed.md | 24 +++++++++++++++++++
 tests/hashtag-preferences.test.mjs            | 14 +++++------
 2 files changed, 31 insertions(+), 7 deletions(-)
 create mode 100644 docs/agents/task-logs/daily/2026-02-24_20-46-12_ci-health-agent_completed.md

diff --git a/docs/agents/task-logs/daily/2026-02-24_20-46-12_ci-health-agent_completed.md b/docs/agents/task-logs/daily/2026-02-24_20-46-12_ci-health-agent_completed.md
new file mode 100644
index 00000000..46322cb0
--- /dev/null
+++ b/docs/agents/task-logs/daily/2026-02-24_20-46-12_ci-health-agent_completed.md
@@ -0,0 +1,24 @@
+# CI Health Agent Task Log
+
+**Agent:** ci-health-agent
+**Cadence:** daily
+**Date:** 2026-02-24
+**Status:** Completed
+
+## Summary
+
+Identified and fixed a flaky test in `tests/hashtag-preferences.test.mjs` that was causing intermittent CI failures.
+
+## Details
+
+### 1. Flake Identification
+- **Test:** `load applies same-timestamp updates deterministically with overlap fetch` in `tests/hashtag-preferences.test.mjs`.
+- **Symptom:** Assertion error where `expected: ['oldpref']` but `actual: ['newpref']` on the first load.
+- **Root Cause:** The test mocked `nostrClient.fetchListIncrementally` using a `callCount` variable to determine when to return a newer event ("cipher-new"). The test author assumed `hashtagPreferences.load()` triggers a single fetch call. However, `load()` triggers concurrent fetches for multiple kinds (30015 and 30005), causing `callCount` to increment twice during the *first* load operation. This caused the mock to return the "future" event prematurely.
+
+### 2. Resolution
+- **Fix:** Modified the mock implementation to condition the return of the new event on `params.since > 0` (which correctly distinguishes the incremental update fetch from the initial load) rather than `callCount`.
+- **Verification:** Updated test assertions to correctly verify that incremental fetching occurs, handling the multi-call nature of the implementation. Ran `node tests/hashtag-preferences.test.mjs` and confirmed it passes consistently.
+
+## Artifacts
+- Created `artifacts/ci-flakes-20260224.md` with failure details.
diff --git a/tests/hashtag-preferences.test.mjs b/tests/hashtag-preferences.test.mjs
index 2d4604c7..e1a12dee 100644
--- a/tests/hashtag-preferences.test.mjs
+++ b/tests/hashtag-preferences.test.mjs
@@ -875,7 +875,7 @@ test(
             tags: [["encrypted", "nip04"]],
           },
         ];
-        if (callCount > 1) {
+        if (params.since > 0) {
           events.push({
             id: "ffff",
             created_at: 1500,
@@ -902,12 +902,12 @@ test(
         ["newpref"],
         "newer same-second event should replace prior snapshot",
       );
-      assert.ok(sinceCalls.length >= 2);
-      assert.equal(
-        sinceCalls[1],
-        1499,
-        "second fetch should include one-second overlap",
-      );
+
+      // Verify incremental fetch behavior.
+      // Since load() may fetch multiple kinds concurrently, checking specific indices is unreliable.
+      // Instead, verify that at least one call used the incremental since timestamp.
+      const incrementalCalls = sinceCalls.filter((since) => since === 1499);
+      assert.ok(incrementalCalls.length >= 1, "second fetch should include one-second overlap");
     } finally {
       nostrClient.fetchListIncrementally = originalFetchIncremental;
     }