Fixes SOU-1150

Problem

Large repositories could be indexed twice within a single reindex interval due to a race in RepoIndexManager.onJobCompleted (packages/backend/src/repoIndexManager.ts).

The handler did three things in order:

1. Mark the index job COMPLETED (one DB write, which also flips repo.latestIndexingJobStatus).
2. Run several git reads — isRepoEmpty, getCommitHashForRefName, getLatestCommitTimestamp, getLocalDefaultBranch.
3. Update repo.indexedAt (a separate DB write).

Between steps 1 and 3 there is a window — the duration of the git reads in step 2 — where the job is already COMPLETED but indexedAt is still stale. The scheduler (scheduleIndexJobs) polls every reindexRepoPollingIntervalMs (default 1s) and creates a new index job when both:

• indexedAt IS NULL OR indexedAt < now - reindexIntervalMs (still true — step 3 hasn't run), and
• there is no INDEX job in PENDING/IN_PROGRESS (now true — step 1 already flipped it to COMPLETED).

So a poll landing in that window schedules a duplicate index job. On large repos the git reads take long enough that the 1s poll hits the window routinely; the Redlock doesn't help because onJobCompleted runs as a BullMQ completed event handler, after the lock from processJob has already been released (and the duplicate job row is created regardless of execution serialization).

Fix

Run the git reads first, then write status = COMPLETED and indexedAt (plus indexedCommitHash, pushedAt, metadata, defaultBranch) together in a single repoIndexingJob.update with a nested repo update.

Now the job remains IN_PROGRESS for the entire git-read window and only flips to COMPLETED at the same instant indexedAt becomes fresh. The scheduler's two guards can never both pass simultaneously: before the write, the active-job guard blocks; after it, the fresh indexedAt guards.

Verification

Reproduced the original bug locally by injecting a 5s sleep between the COMPLETED write and the indexedAt update — a single repo cascaded into 4 index jobs within ~11s. After the fix, with the sleep moved to before the combined write (so the job stays IN_PROGRESS), no duplicate is scheduled.

• yarn workspace @sourcebot/backend build passes.
• yarn workspace @sourcebot/backend test --run repoIndexManager — 15/15 pass. The "updates repo.indexedAt" test now asserts status: COMPLETED and indexedAt are written in the same repoIndexingJob.update call, which serves as the regression guard.

🤖 Generated with Claude Code

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Fixed a race condition that could cause large repositories to be indexed twice within a single reindex interval.