Greptile Summary

This PR optimizes the GC cleanup functions to avoid SELECT * queries when fetching old request executions and request records, replacing them with targeted SELECT calls that only retrieve the integer fields required for the cleanup logic (id, project_id, data_storage_id, request_id). This eliminates unnecessary transfer of large JSON blob columns (request_body, response_body, response_chunks) from PostgreSQL, which could cause OOM crashes during GC runs.

• cleanupOldRequestExecutions now selects only id, project_id, data_storage_id, and request_id — exactly the fields used by cleanupExecutionExternalStorage to build object-storage keys.
• cleanupOldRequestsRecords now selects only id, project_id, and data_storage_id — exactly the fields used by cleanupRequestExternalStorage.

Confidence Score: 5/5

Safe to merge — the change is narrowly scoped to restricting the SELECT column list in two batch-query loops, and every field consumed by the downstream cleanup helpers is present in the new select list.

Both cleanup functions only use id, project_id, data_storage_id, and (for executions) request_id to build external-storage object keys and DB delete predicates. The schema confirms data_storage_id is nullable and stored as a plain int in the Go struct; the existing == 0 guard already handles the NULL case correctly both before and after this change. Pagination relies on DELETE removing the fetched rows so the next query naturally advances — that logic is unchanged. No unselected field is read anywhere in the affected code paths.

No files require special attention.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant GC as GC Worker
    participant DB as PostgreSQL
    participant ES as External Storage

    Note over GC,DB: Before fix: SELECT * (all blob columns)
    GC->>DB: "SELECT * FROM request_executions WHERE created_at < cutoff ORDER BY id LIMIT 500"
    DB-->>GC: 500 rows incl. request_body / response_body / response_chunks (MBs)

    Note over GC,DB: After fix: SELECT id, project_id, data_storage_id, request_id
    loop Batch loop
        GC->>DB: "SELECT id, project_id, data_storage_id, request_id FROM request_executions WHERE created_at < cutoff ORDER BY id LIMIT 500"
        DB-->>GC: 500 rows (integers only, tiny payload)
        GC->>ES: DeleteData(keys derived from id / project_id / request_id)
        ES-->>GC: OK
        GC->>DB: DELETE FROM request_executions WHERE id IN (...)
        DB-->>GC: deleted count
    end

_{Reviews (1): Last reviewed commit: "fix(gc): avoid SELECT * when querying ol..." | Re-trigger Greptile}