notification-service: fetchEvents has no pagination loop, so bursts over 100 events are silently dropped forever

[abayomicornelius]

Area

Notification Service / Reliability

Complexity

Medium

File(s)

notification-service/src/listener.ts (fetchEvents, lines ~109-120)

Problem

server.getEvents is called with pagination: { limit: 100 } and only the single returned page is consumed — there's no loop over a cursor/response.cursor for additional pages. If more than 100 ScoreChanged events occur within one poll window (e.g. after downtime, a backfill, or a busy period), events beyond the first 100 are never fetched, yet poll() still advances the cursor to latestLedger.sequence. Those events are gone permanently, not just delayed.

Scope

In:

• Loop getEvents calls until all pages for the range are consumed before returning from fetchEvents.

Out:

• Rate-limiting/backpressure for pathologically large backlogs.

Acceptance Criteria

• fetchEvents retrieves all pages of events for a ledger range, not just the first 100
• A test with a mocked multi-page response (>100 synthetic events) asserts all events are returned and processed

[drips-wave]

@abayomicornelius This issue could not be added to the Stellar Wave Program because the per-repo points budget would be exceeded (25000 / 25000 points already used). The label has been automatically removed.

The budget resets at the end of each Wave. You can review the remaining budget for your repos on the Orgs & Repos page.

ℹ️ Learn more about points budgets