Repository navigation
fix(api): automation pruner passed its provider list as one bind parameter - #6756
Conversation
…meter
`provider <> ALL(${PAYLOAD_READBACK_PROVIDERS})` sends the JS array as a
single parameter, which Postgres receives as a record and refuses to cast
to text[]. Every run since deploy has failed on it — 811 errors in 24h,
so the job has never pruned a row.
Built as an explicit list instead, the same way the active-subscription
statuses are handled in load-custom-session-data. Verified against a copy
of production: the statement now plans as an index scan on
automation_events_prunable_idx and executes in 50ms.
It prunes nothing today, which is correct rather than broken:
automation_events was created on 2026-08-15 by migration 0071, so no row
is yet older than the 7-day window. It has work from tomorrow.
Worth recording why this reached production: I hit the identical array
binding failure in a throwaway script earlier the same day and fixed it
there, but shipped this route without ever executing it against a
database. The partitioning work beside it was validated end to end; this
was not.
Claude-Session: https://claude.ai/code/session_014D6wif8HDRCXEFf5Ku4w7V
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe prune-payloads route now builds individually bound SQL values for excluded providers. The pruning query uses these values in a ChangesPrune Payload Provider Filtering
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change fixes provider filtering so the payload pruner can execute correctly. It is localized to one route, and no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🧹 Preview Cleanup CompleteThe following preview resources have been cleaned up:
Thank you for your contribution! 🎉 |
The automation payload pruner has failed on every run since it deployed — 811 errors in 24h, last one two minutes before I opened this. It has never pruned a row.
provider <> ALL(${PAYLOAD_READBACK_PROVIDERS})sends the JS array as a single bind parameter. Postgres receives it as a record and won't cast it totext[].Fixed by building an explicit list with
sql.join, the same wayACTIVE_SUBSCRIPTION_STATUSESis handled inload-custom-session-data.ts.Verified against a copy of production
Index Scan using automation_events_prunable_idx, no sortIt prunes 0 rows today, which is correct rather than broken:
automation_eventswas created on 2026-08-15 by migration0071, so nothing is older than the 7-day window yet. It has work from tomorrow.Related correction
I previously described
automation_eventsas having been accumulating unpruned for a long time. It's 7 days old. That makes the growth rate worse than I said, not better — 35 GB in 7 days, ~5 GB/day, with nothing deleting it. The 4.55M rows currently in it are all within the retention window.Why this reached production
I hit the identical array-binding failure in a throwaway script earlier the same day and fixed it there, then shipped this route without ever executing it against a database. The partitioning work beside it was validated end-to-end against a real production copy; this route was not. The check that would have caught it is the one I ran today: execute the actual statement against a real branch before merging.
https://claude.ai/code/session_014D6wif8HDRCXEFf5Ku4w7V
Summary by cubic
Fixes the automation payload pruner by replacing
provider <> ALL($1)with an explicitNOT IN (...)list built viasql.join. The old query bound the provider array as one parameter, which Postgres rejected, so every run failed; the new query runs successfully.Review notes:
["google_calendar"].sql.join, emitting parameterized values to avoid the array-binding bug.Operational notes:
automation_events_prunable_idxand completes in ~50 ms per batch.automation_eventsis 7 days old and the retention window is 7 days. Expect first deletions starting tomorrow.Written for commit c5d614c. Summary will update on new commits.
Summary by CodeRabbit