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

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Apr 10, 2026 0:50am

@BugBot review

PR Summary

Medium Risk
Changes the selection criteria for which logs are eligible for deletion/archiving by switching to a workspace subquery and using startedAt for retention, which could alter cleanup coverage if the new join/field differs from prior behavior.

Overview
Fixes the log-cleanup cron query to avoid generating oversized IN (...) parameter lists by selecting free-plan workspaces via a workspace/subscription subquery instead of fetching all free user IDs into memory.

Also adjusts the retention predicate to compare against workflowExecutionLogs.startedAt (and simplifies early-return logic/logging), keeping the rest of the archive/delete flow unchanged.

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

Greptile Summary

This PR replaces a two-step memory-bound query (fetch all free-user IDs → pass as IN params) with a single Drizzle subquery, correctly fixing the "too many params" PostgreSQL error that was breaking the log cleanup cron job. The core fix is sound and the approach is idiomatic for Drizzle ORM.

One incidental change deserves attention: the retention filter was silently switched from createdAt to startedAt in the WHERE clause, which has slightly different semantics and was not called out in the PR description.

Confidence Score: 4/5

Safe to merge after confirming the startedAt vs createdAt filter change is intentional.

The core subquery fix is correct and directly addresses the production breakage. The only unresolved concern is the unannounced semantic change from createdAt to startedAt in the retention filter — practically minor (milliseconds difference) but deserves explicit acknowledgment from the author before merging.

apps/sim/app/api/logs/cleanup/route.ts — confirm the startedAt field change on line 90 is deliberate

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Cron as Cron Job
    participant Route as /api/logs/cleanup
    participant DB as Database

    Note over Route,DB: Before (broken — too many params)
    Cron->>Route: GET request
    Route->>DB: SELECT id FROM user (all free users)
    DB-->>Route: [userId1, userId2, ..., userIdN]
    Route->>DB: SELECT id FROM workspace WHERE billedAccountUserId IN ($1,$2,...,$N)
    Note right of DB: Fails when N is large
    DB-->>Route: Error: too many params

    Note over Route,DB: After (fixed — subquery)
    Cron->>Route: GET request
    Route->>DB: SELECT logs WHERE workspaceId IN (SELECT workspace.id FROM workspace LEFT JOIN subscription WHERE subscription.id IS NULL) AND startedAt < retentionDate LIMIT 2000
    DB-->>Route: [log batch]
    Route->>DB: Archive + delete each log
    Route-->>Cron: results, complete, batchLimitReached

_{Reviews (3): Last reviewed commit: "perf(log): use startedAt index for clean..." | Re-trigger Greptile}

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

^{_{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}}

@greptile

@cursor review

@greptile

@cursor review