Description

The BatchReplayEvents handler sets an astronomically high default page size of 2,000,000,000 (2 billion) when no pageable filter is provided. This could load an enormous number of events into memory, potentially causing OOM crashes.

Context

• File: api/handlers/event.go:215-218
• Component: Event batch replay

Current Behavior

ep := datastore.Pageable{}
if data.Filter.Pageable == ep {
    data.Filter.Pageable.PerPage = 2000000000
}

When a request to /v1/projects/{projectID}/events/batchreplay is made without pagination parameters, the entire event table for that project is loaded into memory. For projects with millions of events, this will:

1. Consume massive amounts of RAM
2. Potentially crash the server with OOM
3. Create an implicit DoS vector — a single API call can exhaust server memory

Expected Behavior

The batch replay should use a reasonable default page size and process events in chunks/batches, or require explicit pagination.

Suggested Fix

Use a reasonable maximum batch size and process in chunks:

  ep := datastore.Pageable{}
  if data.Filter.Pageable == ep {
-     data.Filter.Pageable.PerPage = 2000000000
+     // Use a safe maximum batch size; process larger sets in chunks
+     data.Filter.Pageable.PerPage = 10000
  }

For truly large batch replays, consider adding a streaming/chunked approach that processes events in batches of 10K-100K.

Alternatively, if the full-table scan is intentional, add a hard cap and document it:

const maxBatchReplaySize = 100000
if data.Filter.Pageable.PerPage > maxBatchReplaySize {
    data.Filter.Pageable.PerPage = maxBatchReplaySize
}

Impact

• Severity: Medium — Can cause server instability on projects with large event stores
• Who is affected: Self-hosted deployments with projects containing many events

Positively — happy to submit a PR if this is welcome.