[waleedlatif1]

Summary

An organization's audit listing scopes rows with one OR predicate (the org's workspaces, or workspace-less rows naming the org). With no filter, or only a time range (the audit page's default "Past 30 days" view), no index returns that OR in listing order, so each page collects every in-scope row inside the range and sorts it. For a busy organization that becomes a scan over a large part of audit_log, long enough to hit replica recovery conflicts.

This PR changes only those listings, the ones narrowed by nothing but a time range:

• The page ids come from a disjoint union. Each organization workspace gets one keyset scan of audit_log_workspace_created_at_id_idx, through unnest(...) cross join lateral (... limit page). The metadata-attributed org-level rows are read through audit_log_org_level_created_at_id_idx (0444). The organization-resource rows that don't name the org in metadata get a small resource_idx read. Every part is ordered and limited to one page, so the first page of the union is exactly the first page of the scope, and union all can't produce duplicates because the parts are disjoint. Workspace ids are deduplicated.
• The time range is kept as written (created_at >= / <=). It is also stated as implied bounds on the sort key (date_trunc('milliseconds', created_at) >= / <= date_trunc(bound)). Because date_trunc never decreases, these bounds drop no row the exact predicate keeps, and each scan starts and stops at the range.
• The cursor is the same keyset position, written as a row comparison so the scan can seek to it.

Any other filter (action, resource type/id, actor, actor email, workspace, search, alone or combined with time) keeps the single predicate unchanged, SQL and parameters byte for byte. Under such a filter a per-workspace scan cannot stop after a page; that is what made #9419's fan-out slow, and #9438 reverted it. The single predicate lets the filter's own index drive.

queryAuditLogs now takes the scope and the filters instead of prebuilt SQL so it can make this choice. Callers updated: list and export use cases, /api/v1/audit-logs. buildOrgScopeCondition output is unchanged, so the detail read and the data drain are untouched.

No schema change. audit_log_workspace_created_at_id_idx stays: this path depends on it, and workspace-filtered listings already use it today.

Type of Change

• Other: performance

Testing

• list-scope.integration.ts pages through 13 filter shapes (none, start, end inside a millisecond, range, action, action+time, resource type(s), resource, actor, workspace, search). Each runs with current members only and with departed members included, at page sizes 1/3/7/100, with and without the byte budget. Every run must match the single predicate's order exactly. The fixture covers workspace rows, org-level rows of both kinds, another org's rows, departed and null actors, four rows per PostgreSQL millisecond (ties broken by id), a duplicated workspace id, and a workspace the organization no longer holds.
• list-plans.integration.ts checks the plans. Unfiltered, departed-included, after-cursor, start-date and date-range listings must read each workspace with an Index Scan Backward on the keyset index directly under the limit that stops it, with the range and cursor in its Index Cond. These checks fail on the previous single-predicate listing. Every narrowed shape must keep the single predicate (no fan-out).
• Mutation checks: dropping the workspace-id dedupe, dropping the exact time predicate, or routing everything back to the single predicate each turns these tests red.
• A one-off compile of every narrowed filter combination, with and without a cursor, across three scopes produced SQL text and parameters identical to staging.
• On the production replica, the busiest organization's unfiltered and 30-day listings go from a scan of the whole scope to a few thousand buffer hits. A one-hour window costs about the same as today. Organizations with many workspaces stay bounded at one short scan per workspace.
• Audit-log and data-drain integration suites, related unit suites, lint, check:audits, type-check, test:scripts.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Oct 29, 2026 6:40pm UTC

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no new actionable issue was found.

Summary

The PR uses per-workspace keyset scans for audit listings filtered only by time. Other filters keep the existing query.

• Time-only audit-log pages load with short scans across each workspace.

The earlier unnumbered finding is addressed by the changed actor mix. waleedlatif1 explicitly declined a rows-read or buffer assertion, accepting plan-only checks because the intended contract is the scan's cost bound and citing production measurements.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Audit listing] --> B{Filter beyond time?}
  B -->|Yes| C[Existing single-scope query]
  B -->|No| D[Limited scan per workspace]
  B -->|No| E[Limited organization-level scans]
  D --> F[Combine and order page IDs]
  E --> F
  F --> G[Read page rows]
  C --> H[Return page and cursor]
  G --> H

Loading

_{Reviews (2) · Last reviewed commit: "test(audit-logs): plan the keyset listin..." · Reviewed by Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 9 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}