[Audit] Hash-chain concurrent write race — activity_logs can fork

[2witstudios]

Summary

activity_logs hash-chain writes are currently vulnerable to concurrency/fail-open behavior: latest-hash lookup and insert are not serialized with row locking, and hash-read errors degrade to continuing with weak chain input.

Evidence

• Non-transactional path reads latest hash then inserts without lock:
  • /Users/jono/production/PageSpace/packages/lib/src/monitoring/activity-logger.ts:469
  • /Users/jono/production/PageSpace/packages/lib/src/monitoring/activity-logger.ts:493
• Transactional path also reads latest hash without explicit row lock semantics:
  • /Users/jono/production/PageSpace/packages/lib/src/monitoring/activity-logger.ts:558
• On hash-read failure, code returns fallback values and continues:
  • /Users/jono/production/PageSpace/packages/lib/src/monitoring/activity-logger.ts:178
• Security audit chain uses FOR UPDATE locking pattern as a stronger reference:
  • /Users/jono/production/PageSpace/packages/lib/src/audit/security-audit.ts:166

Why This Matters

Under concurrent inserts, two events can derive from the same predecessor hash, creating chain forks and reducing forensic reliability.

Proposed Work

1. Serialize activity-chain predecessor reads using transactional locking (or equivalent deterministic sequencing).
2. Define explicit failure mode for hash-read failures (fail closed or queue retry) instead of silent weak fallback.
3. Add stress tests for concurrent writes and deterministic chain continuity.

Acceptance Criteria

• Concurrent activity writes do not produce chain forks.
• Hash lookup failures are handled by an explicit, observable policy.
• Tests validate chain integrity under concurrency and failure injection.