// Audit exception safety and failure atomicity across all throw sites
Differential audit comparing matched code paths that should behave identically. Spawns one auditor per sibling pair (sync/async, bounded/unbounded, view consistency, bulk vs single, generated node variants, read fast vs slow) and requires a concrete witness scenario where the two paths diverge observably.
Heavyweight history-mining bug audit. Walks the caffeine module's git history chronologically (oldest to HEAD), maintains a forward-tracked issue database, and surfaces concerns introduced by past commits that were never resolved. Catches bugs that snapshot mining cannot — half-fixes invisible from current state, latent+trigger pairs across multi-commit interactions, and partial refactors. Slow (~8-14 hours) and rare-run (every several months or before a major release).
Find places where documented API contracts and the implementation diverge
Analyze feature interaction pairs and triples for concurrent defects
Analyze concurrent iteration and view consistency guarantees
Java Memory Model audit of all VarHandle/volatile field access modes
| name | audit-exception-safety |
| description | Audit exception safety and failure atomicity across all throw sites |
| context | fork |
| agent | auditor |
| disable-model-invocation | true |
Audit the cache for exception safety defects. For every code path where exceptions can be thrown, determine whether the cache is left consistent.
Assume at least one exception safety bug exists. If your analysis yields zero findings, re-examine catch-commit-rethrow paths — explain specifically why no exception scenario leaves inconsistent state.
Priority #1: catch-commit-rethrow in doComputeIfAbsent and remap. This is the most commonly misunderstood pattern and historically the most fragile. Trace the EXACT sequence of committed mutations, notification delivery, and exception propagation for every exception type.
User-provided code that can throw:
Runtime exceptions: 6. OutOfMemoryError during node/reference allocation 7. StackOverflowError from deep re-entrancy 8. RejectedExecutionException from executor
For each throw site:
List every mutation already committed before the throw point.
Determine whether the catch block rolls back or commits.
Check for:
For catch-commit-rethrow (doComputeIfAbsent, remap), verify:
For OutOfMemoryError specifically:
For each defect: state the throw site, mutations committed, inconsistent state, and a concrete triggering scenario.
