fix(index): prevent stack overflow via async pendingRebuild

[martinmarsian]

Summary

performFullRebuild() called itself synchronously from its own defer block when pendingRebuild was true. Under sustained file-system activity (pendingRebuild staying true across consecutive builds), this produces 400+ frames of recursive self-invocation and terminates the process with SIGBUS.

• Replace the direct recursive call with indexQueue.async { [weak self] in self?.performFullRebuild() } so the next rebuild is scheduled as a fresh stack frame

Files changed

• Sources/wired3/Controllers/IndexController.swift (1 file, 4 lines)

Test plan

• Start server with a large files directory and trigger rapid file-system changes that keep re-indexing active — process should not crash
• Normal re-index flow (SIGUSR1 or UI button) still works

🤖 Generated with Claude Code

[github-actions]

Claude finished @nark's task in 1m 15s —— View job

---

Code Review — fix(index): prevent stack overflow via async pendingRebuild

Tasks

• Read changed file and diff
• Analyse correctness, thread safety, and edge cases
• Post review

---

✨ Nice catch and clean fix. The root cause is well-diagnosed — defer calling performFullRebuild() synchronously from within itself creates unbounded recursion whenever finalisation keeps failing (the recoverIndexAndFTS5() path sets pendingRebuild = true unconditionally). Switching to indexQueue.async is exactly the right tool here: it unwinds the current stack before the next rebuild starts, while the serial queue guarantees that only one rebuild runs at a time and that isIndexing/pendingRebuild are always read/written in serial order.

Thread-safety walk-through (everything checks out):

• isIndexing and pendingRebuild are accessed only on indexQueue ✓
• cancelCurrentRebuild goes through cancelLock ✓
• indexQueue is serial → no window where a concurrent indexFiles() dispatch can race with the newly queued rebuild ✓
• [weak self] avoids a retain cycle ✓

---

💡 Suggestion — persistent-error retry loop (not a blocker, but worth thinking about):

The async dispatch fixes the SIGBUS, but if the SQLite error that triggered recoverIndexAndFTS5() is persistent, the server will now loop continuously:

performFullRebuild → finalisation error
  → recoverIndexAndFTS5()           (sets hasFTS5 = false on failure)
  → pendingRebuild = true
  → defer dispatches next rebuild
  → same error again …

In practice the loop is bounded by traversal time (seconds-to-minutes per iteration, not a CPU spin), and recoverIndexAndFTS5() dropping/recreating the FTS5 table should resolve the common case. But if the underlying DB is entirely unwritable, you get a perpetual rebuild storm. A small guard — e.g. a consecutive-failure counter that backs off exponentially or disables auto-rebuild after N failures — would make the recovery story airtight. That said, this behaviour pre-dates this PR and is clearly out of scope here.

---

💡 Minor — comment verbosity (nit, ignore if you like):

The added // IMPORTANT: block re-states what the code now self-evidently shows. The first two lines that already existed (// If cancelled, forceReindex() …) are the important ones. The new block could be condensed to one line explaining the overflow scenario, rather than restating the async solution. Purely cosmetic.

---

The fix is correct and safe to merge as-is. Good work tracking down a tricky crash path, @martinmarsian.