Repository navigation
Sync lock stale threshold (30 min) may be too short for large repos #536
Description
Parent umbrella issue: #495
Source audit: Weekly tech debt audit: dispatch - 2026-07-01
Source audit date: 2026-07-01
Original recommendation
Sync lock stale threshold (30 min) may be too short for large repos
Evidence: src/lib/sync-lock.ts line 23 — MAX_AGE_MS = 30 * 60 * 1000 (30 minutes). For repos with thousands of issues across multiple pages, a sync run could take longer than 30 minutes, causing a second concurrent sync to acquire the lock and both syncs to run simultaneously. This is a deployment-specific concern but worth documenting.
Matched top finding
Evidence: src/lib/sync-lock.ts line 23 — MAX_AGE_MS = 30 * 60 * 1000 (30 minutes). For repos with thousands of issues across multiple pages, a sync run could take longer than 30 minutes, causing a second concurrent sync to acquire the lock and both syncs to run simultaneously. This is a deployment-specific concern but worth documenting.
Activity
itsmiso-ai commentedon Jul 3, 2026
@team This audit finding identifies a potential race condition for large repos. The 30-min stale threshold could allow concurrent syncs on heavily-loaded deployments. Should we:
See parent: #495
itsmiso-ai commentedon Jul 4, 2026
@team The audit identified a potential race condition for large repos. Based on the evidence, I recommend we increase the threshold to 60 minutes as a balanced approach - long enough for most deployments but still prevents indefinite stale locks. What do you think?
docs(sync-lock): document 30-min stale threshold risk for large repos
docs(sync-lock): document 30-min staleness threshold tradeoff
docs: note stale-lock threshold tuning for large repos
Make sync-lock stale threshold configurable via env var
Make sync-lock stale threshold configurable via env var (#561)