From 042b9aa295dc32fa2aa33707daf0d82b0769f03a Mon Sep 17 00:00:00 2001 From: Chris Coutinho Date: Thu, 4 Jun 2026 23:49:03 +0200 Subject: [PATCH] fix(tests): moderate re-scan interval to stop multi-user index churn MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lowering VECTOR_SYNC_SCAN_INTERVAL to 5s (previous commit) fixed user discovery on nc31 but exposed re-scan churn on the slower nc32 runner: each scan re-queues the user's entire corpus, so a 5s cadence floods the single processor worker faster than it drains (pending climbed to 20-30+ while indexed stayed 0, status "syncing"). Discovery latency and re-scan churn are separate knobs. Keep USER_POLL_INTERVAL short (5s) for prompt discovery — the per-user scanner runs its initial scan immediately on start, so the corpus is queued once right away — but restore a moderate SCAN_INTERVAL (30s) so re-scans don't re-flood the queue. Indexing of the one-time initial scan completes well inside the test's 90s budget; a note created just after that scan is still picked up by the 30s re-scan. Co-Authored-By: Claude Opus 4.8 (1M context) --- docker-compose.yml | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/docker-compose.yml b/docker-compose.yml index 151d9296..1be09d8d 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -160,15 +160,21 @@ services: - TOKEN_STORAGE_DB=/app/data/tokens.db - ENABLE_SEMANTIC_SEARCH=true - # Fast discovery + scan cadence for integration tests: the multi-user - # background-sync suite provisions a user, creates a note, then waits - # ~90s for it to be indexed. With the production defaults (user-poll 60s - # + scan 60s) a freshly-provisioned user often isn't even discovered - # within that budget, so the wait times out (note never indexed). Match - # the single-user service's short cadence so discovery + scan + index - # complete promptly under CI load. + # Tuned cadence for the multi-user background-sync integration suite, + # which provisions a user, creates a note, then waits ~90s for it to be + # indexed. Two independent knobs matter here: + # * USER_POLL_INTERVAL gates how fast the background-sync user manager + # *discovers* a freshly-provisioned user (its scanner runs an initial + # scan immediately on start). The 60s default left too little of the + # 90s budget, so drop it to 5s for prompt discovery. + # * SCAN_INTERVAL gates *re-scan* churn. Each scan re-queues the user's + # whole corpus, so a very short interval (e.g. 5s) floods the single + # processor worker faster than it drains on slower CI runners + # (pending climbs, indexed stays 0). Keep it moderate: the immediate + # initial scan already indexes the corpus once; 30s re-scans avoid + # the flood while still catching a note created just after that scan. - VECTOR_SYNC_USER_POLL_INTERVAL=5 - - VECTOR_SYNC_SCAN_INTERVAL=5 + - VECTOR_SYNC_SCAN_INTERVAL=30 - VECTOR_SYNC_PROCESSOR_WORKERS=1 # OAuth credentials for background sync (optional - uses DCR if not provided)