eRPC Finalized Cache Postgres Volume Full

When an eRPC finalized cache uses ttl: 0, the Postgres volume can grow until writes fail. Do not fix it by blindly deleting active-chain cache; first separate retained value, retired-chain rows, alarm thresholds, and the true disk ceiling.

Runbook: No-Expiry Cache Needs A Disk Contract

1. Confirm the outage boundary first: volume at 100%, Postgres offline, DNS or connection failures, and whether writes fell through to paid upstream RPC.
2. Keep ttl: 0 only for active finalized data with clear value, such as cold-resync speedup or paid-RPC avoidance.
3. Do not apply a blanket TTL if it evicts deep-history cache that is expensive to rebuild. Use chain and finality scope instead.
4. Identify retired or decommissioned-chain rows. Delete those first, then run the correct vacuum strategy for the hosting environment.
5. Add a warning at about 75% and a hard floor by absolute free GB. A percentage threshold alone can be misleading on small volumes.
6. Track growth by chain, method, and finality. The policy should estimate when the larger volume will fill again.
7. Record the fallback cost. If cache misses trigger paid RPC, the disk policy is also a cost-control policy.

I would keep the fix centered on a cache-retention contract rather than a blanket TTL.

Before pruning, I would capture:
- current volume used/free and Postgres table sizes
- row counts by chain, method, and finality
- which chains are active versus retired/decommissioned
- whether cache misses fall through to paid RPC or raw upstream
- the alarm threshold and the estimated days until the next full-volume date

For the durable fix, I would keep active-chain finalized ttl:0 only where it has clear resync/cost value, prune retired-chain rows first, VACUUM after the scoped delete, and add a 70-80% volume alarm plus an absolute free-GB floor. That preserves the useful finalized cache while making the next disk cliff visible.

Do Not Delete First

• Active-chain finalized cache that protects resync speed or avoids paid upstream RPC.
• Any rows before recording chain, method, finality, and row-count evidence.
• Postgres data files or volumes without a backup, rollback, and hosting-specific vacuum plan.
• The alarm and cost evidence that proves why the cache policy is worth keeping.