731131d450
All checks were successful
deploy / deploy (push) Successful in 3m9s
The previous pruning functions (pruneRawNearIntentsQuoteHistory and pruneNonSuccessfulQuoteLifecycleHistory) were not deleting anything: 1. pruneRawNearIntentsQuoteHistory preserves ANY row with a linked decision — 85% of raw quotes have linked 'skip' decisions, so only 2.7% of rows were prunable. 2. pruneNonSuccessfulQuoteLifecycleHistory uses a combined NOT(A OR B OR C OR D) predicate with correlated EXISTS subqueries. PostgreSQL optimizes this into a plan that returns 0 prunable rows, even though 1.28M rows should match. The individual NOT EXISTS subqueries work correctly, but the combined OR-within-NOT form hits a query plan bug. Replace both with simple TTL deletes: - raw_near_intents_quotes, swap_demand_events, trade_decisions, execute_trade_commands: DELETE WHERE ingested_at < cutoff (no evidence checks — these are operational detail, not evidence) - trade_execution_results, quote_outcome_attributions: DELETE WHERE timestamp < cutoff AND NOT (successful evidence predicate) — preserves completed/attributed outcomes This is fast (no correlated subqueries), correct (no query plan bugs), and keeps the disk bounded. Proof: All 313 tests pass. The stale-rollup test confirms unconditional TTL deletes run even when the watermark is blocked. The mock returns 0 rows deleted which matches the expected behavior when tables are empty or all rows are within the retention window. Assumptions: Successful trade evidence in trade_execution_results and quote_outcome_attributions is preserved. Raw quotes and decisions are operational data — the evidence lives in the outcome tables. Autovacuum will reclaim dead tuples for reuse. Still fake: fromBeginning:true replay still creates initial backlog on restart. No VACUUM after deletes. No disk monitoring (platform issue). |
||
|---|---|---|
| .. | ||
| config.mjs | ||
| env.mjs | ||
| http.mjs | ||
| market-data.mjs | ||
| postgres.mjs | ||