Bug #2 (CRITICAL): Early write at line 2664 was using OLD score (0) before
scoring happened. This caused:
1. Data written TWICE (wasteful)
2. Race condition: ip_data briefly has incorrect score before being corrected
3. Lock contention: flock hit twice per IP per scan
4. Inconsistent state: old score visible to other processes between writes
Root cause: We incremented hits before threshold check, forcing early write
before scoring completed.
Fix: Move hits increment to AFTER all scoring (line 2928), before final write.
This way:
1. Threshold calculation still uses LOADED hits from ip_data (unchanged)
2. Score is fully calculated before increment
3. SINGLE write with complete, correct data
4. No race conditions or data inconsistency
Data flow (AFTER FIX):
1. Load hits from ip_data (for threshold calculation)
2. Check if count > threshold
3. Do ALL scoring (lines 2902-2927)
4. Increment hits (line 2928) - MOVED HERE
5. Single write with complete data (line 2931)
Example: IP detected twice
- Scan 1: Load hits=0, threshold=3, score SYN, hits becomes 1, write score|1
- Scan 2: Load hits=1, threshold=2 (lowered), score SYN, hits becomes 2, write score|2
Now threshold calculation uses LOADED hits (0 then 1), not incremented hits.
Incremented hits only used for persistence.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
cschantz
abf0a7b943