fix: P9 — consolidate lock hoist, Condvar backpressure, TOCTOU hardening

[ajianaz]

What

Performance and safety improvements addressing backlog items from cora re-scan analysis.

Why

These issues were identified during the P8 post-merge cora re-scan (163 findings) and represent the highest-impact backlog items:

1. Lock contention in consolidate — write lock acquired + index saved per dedup pair (N iterations = N lock + N saves)
2. CPU spin under load — server backpressure used yield_now() spin loop instead of parking threads
3. TOCTOU race conditions — file existence check then open/create pattern allows race between processes
4. Integer overflow risk — next_key + 1 could panic on u64 overflow (unlikely but undefined behavior)

Changes

consolidate.rs — Lock hoist + single save

• Acquire index write lock once before the dedup loop
• Single index.save() after all removals complete
• Reduces N lock acquires + N disk saves → 1 lock + 1 save

server/main.rs — Condvar backpressure

• Replace atomic counter + spin-yield with (Mutex<usize>, Condvar) pair
• Main accept loop parks when at capacity instead of burning CPU
• Workers notify_one() on completion to wake the accept loop
• Preserves spawn-error slot release semantics

vector.rs — TOCTOU + overflow hardening

• load_or_create: OpenOptions::create_new(true) replaces if !exists() { write() } — atomic file creation eliminates race
• Key mapping load: match read_to_string() replaces if exists() { read() } — eliminates check-then-read race
• saturating_add(1) for next_key prevents u64 overflow panic at max value

Testing

• Tests: 476 pass, 0 fail
• Clippy: 0 warnings
• Cora pre-commit: clean pass

[github-actions]

🔍 Cora AI Code Review

❌ Blocked — critical issues found.

🔴 Error (1)

• crates/uteke-core/src/consolidate.rs:258 — The write lock on self.index is now acquired once before the loop and held across all iterations. Inside the loop, self.delete_memory(...) is called, which likely acquires its own database lock (or the Uteke mutex). If any other code path acquires the DB lock first and then tries to read/write the index, this creates a lock-ordering inversion that can deadlock. Additionally, holding the write lock for the entire duration (including all SQLite operations) serializes and blocks all index access even during slow DB I/O, significantly reducing concurrency.

---

Review powered by cora-code · BYOK · MIT