The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	May 22, 2026 3:27am

PR Summary

Medium Risk
Changes add new DB-backed metadata and update log/payload flows to record and prune large execution values, which can affect data retention/deletion behavior and background cleanup correctness. Risk is moderated by bounded batch limits and added tests, but mistakes could lead to premature deletions or leaked storage objects.

Overview
Introduces a new DB-backed metadata system for durable “large execution values” (execution_large_values, execution_large_value_references, execution_large_value_dependencies) and wires it into execution lifecycle.

Durable large-value writes now register owner + dependency metadata when persisting (storeLargeValue), and will clean up the uploaded object (and fail durable writes) if metadata registration fails.

Log and pause/snapshot persistence now updates reference tables (replaceLargeValueReferencesWithClient) so cleanup no longer needs to scan execution_data JSON. The cleanup worker is refactored to delete execution log files in bulk, separately select and delete unreferenced large values based on the new tables (with grace/limits), prune metadata tombstones, and cap Trigger.dev concurrency for the task.

Also tightens chunkedBatchDelete row-limit behavior by tracking attempted rows, and adds focused tests for the new cleanup flow and metadata module.

^{Reviewed by Cursor Bugbot for commit 4812504. Configure here.}

Greptile Summary

This PR replaces a costly LATERAL unnest full-scan approach for large-ref cleanup with a dedicated DB-driven model: three new tables (execution_large_values, execution_large_value_references, execution_large_value_dependencies) track ownership, live references, and transitive dependency closures, enabling efficient bounded cleanup queries.

• New large-value-metadata.ts: registers each large value at write time, records reference sets atomically inside existing transactions (execution log finalization, pause/resume), and prunes stale metadata in bounded batches via pruneLargeValueMetadata.
• cleanup-logs.ts refactor: drops execution-data scanning from the log-deletion batch; replaces it with cleanupLargeExecutionValues reading directly from execution_large_values using a correlated unreferencedLargeValuePredicate, plus a cleanupLargeValueMetadata pass for tombstone/reference GC.
• batch-delete.ts fix: switches the row-limit tracker to a dedicated attempted counter and caps selectChunk to the remaining budget to avoid over-fetching.

Confidence Score: 3/5

The core logic is well-designed and test coverage is solid, but the storage-delete-before-DB-mark ordering in the cleanup path can leave keys permanently uncleanable if the DB update fails and the storage provider is non-idempotent for missing objects.

The cleanup path deletes files from storage before calling markLargeValuesDeleted. If the DB call throws, those keys keep deleted_at = null and are re-selected on every subsequent run. If the storage provider returns errors for non-existent objects, the circuit-breaker (result.deleted === 0 → break) silently skips them every run, leaving them permanently stuck.

apps/sim/background/cleanup-logs.ts (deleteLargeValueKeys ordering) and packages/db/schema.ts (executionLargeValueReferences source column constraint)

Important Files Changed

_{Reviews (1): Last reviewed commit: "fix(large-refs): cleanup based on table ..." | Re-trigger Greptile}