fix(core): align pagination cursor with sort order in execution list

[tom-arnaud]

Summary

Fixes execution list pagination skipping rows when using lastId cursor with startedAt DESC sort order.

The problem

When listing executions via GET /rest/executions with lastId pagination:

1. findRangeWithCount does not set query.order, so the repository defaults to ORDER BY id DESC
2. The cursor filter uses WHERE id < :lastId — an ID-based cursor
3. But the UI displays results sorted by startedAt DESC

This works fine when IDs and startedAt are in the same order. But Wait node workflows break this assumption: executions are created at once (sequential IDs) but resume at different times (non-sequential startedAt).

Concrete example

A workflow triggered at 07:00 creates executions 158685–158773 with Wait nodes. They resume throughout the day:

ID 158690  →  startedAt 18:17  (resumes late)
ID 158725  →  startedAt 18:24  (resumes later)
ID 158772  →  startedAt 18:05  (resumes earlier)

Page 1 (sorted by startedAt DESC, limit 10) ends with id=158725 (startedAt=18:24).

Page 2 sends lastId=158725. The query becomes:

WHERE id < 158725 ORDER BY id DESC LIMIT 10

This returns only 5 rows — missing all executions with id > 158725 but startedAt < 18:24 (e.g. 158772 at 18:05, 158745 at 18:20, etc.). 41 executions become unreachable through pagination.

The fix

Two changes:

1. execution.service.ts: findRangeWithCount now defaults to order: { startedAt: 'DESC' } when no order is specified — consistent with findLatestCurrentAndCompleted which already does this.

2. execution.repository.ts: When ordering by startedAt, the cursor resolves lastId/firstId to their startedAt value via a subquery:

-- Before (bug):
WHERE id < :lastId ORDER BY id DESC

-- After (fix):
WHERE COALESCE(startedAt, createdAt) < (
  SELECT COALESCE(startedAt, createdAt) FROM execution_entity WHERE id = :lastId
)
ORDER BY COALESCE(startedAt, createdAt) DESC

ID-based cursors are preserved for other sort orders (e.g. order.top) where IDs are monotonic.

Test plan

• Verified on production Postgres (428 executions) — bug returns 377 reachable rows, fix returns all 418 within the same time window
• Full pagination simulation confirms 428/428 unique IDs covered with no gaps or duplicates
• Existing integration tests in execution.service.integration.test.ts should still pass (same behavior when IDs and startedAt are in order)
• Edge case: executions with NULL startedAt fall back to createdAt via COALESCE

Related

This affects any workflow using Wait nodes, Send and Wait, or any pattern where executions are bulk-created then resume later.

🤖 Generated with Claude Code

[cubic-dev-ai]

No issues found across 2 files

Architecture diagram

sequenceDiagram
    participant Client as UI / REST API
    participant Service as ExecutionService
    participant Repo as ExecutionRepository
    participant DB as Database (Postgres/SQLite)

    Note over Client,DB: Pagination Flow (GET /rest/executions)

    Client->>Service: findRangeWithCount(query)
    
    opt No sort order provided
        Service->>Service: NEW: Default to { startedAt: 'DESC' }
    end
    
    Service->>Repo: findManyByRangeQuery(query)

    alt NEW: Sort is startedAt DESC
        Repo->>DB: NEW: Subquery: SELECT COALESCE(startedAt, createdAt) FROM execution WHERE id = :lastId
        DB-->>Repo: cursorTimestamp
        
        Repo->>DB: Fetch page WHERE COALESCE(startedAt, createdAt) < :cursorTimestamp ORDER BY timestamp DESC
        Note right of DB: Fixes skip/gap issues from<br/>non-sequential Wait node resumes
    else Other Sort Orders (e.g. top, ID)
        Repo->>DB: Fetch page WHERE id < :lastId ORDER BY id DESC
    end

    DB-->>Repo: Page results (List of Executions)
    Repo-->>Service: ExecutionEntity[]
    
    Service->>Repo: count(query)
    Repo-->>Service: total count
    
    Service-->>Client: { results, count, estimate }

Loading

[CLAassistant]

All committers have signed the CLA.

[n8n-assistant]

Hey @tom-arnaud,

Thank you for your contribution. We appreciate the time and effort you’ve taken to submit this pull request.

Before we can proceed, please ensure the following:
• Tests are included for any new functionality, logic changes or bug fixes.
• The PR aligns with our contribution guidelines.

Regarding new nodes:
We no longer accept new nodes directly into the core codebase. Instead, we encourage contributors to follow our Community Node Submission Guide to publish nodes independently.

If your node integrates with an AI service that you own or represent, please email nodes@n8n.io and we will be happy to discuss the best approach.

About review timelines:
This PR has been added to our internal tracker as "GHC-7684". While we plan to review it, we are currently unable to provide an exact timeframe. Our goal is to begin reviews within a month, but this may change depending on team priorities. We will reach out when the review begins.

Thank you again for contributing to n8n.