audit-exception-safety

---
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:
1. CacheLoader.load / loadAll / reload
2. Weigher.weigh
3. Expiry.expireAfterCreate / expireAfterUpdate / expireAfterRead
4. Mapping functions passed to compute, computeIfAbsent, merge
5. RemovalListener.onRemoval / EvictionListener

Runtime exceptions:
6. OutOfMemoryError during node/reference allocation
7. StackOverflowError from deep re-entrancy
8. RejectedExecutionException from executor

In the jcache adapter, also trace: CacheWriter.write/writeAll/delete/deleteAll
(the spec requires partial-failure bookkeeping), EntryProcessor.process,
ExpiryPolicy methods, and Copier/serialization failures in store-by-value mode.

For each throw site:

1. List every mutation already committed before the throw point.
2. Determine whether the catch block rolls back or commits.
3. Check for:
   - **Phantom entries**: Node in CHM but invisible to eviction/expiration
   - **Orphaned references**: WeakReference created but node rolled back
   - **Counter drift**: weightedSize out of sync with actual entries
   - **Lost notifications**: notifyEviction without notifyRemoval, or vice versa
   - **Leaked futures**: CompletableFuture never completed
   - **Stuck refresh**: refresh flag set but never cleared

4. For catch-commit-rethrow (doComputeIfAbsent, remap), verify:
   - Catches Throwable, not just RuntimeException
   - Committed state is fully consistent
   - Original exception is preserved

5. For OutOfMemoryError specifically:
   - Can AddTask/UpdateTask OOME orphan a CHM entry?
   - Can WeakKeyReference/WeakValueReference OOME leave half-constructed node?

For each defect: state the throw site, mutations committed, inconsistent
state, and a concrete triggering scenario.

More agent context in ben-manes/caffeine

36 other files this repository gives its agents.