notification-service: listener silently advances the ledger cursor when the events fetch itself fails

[abayomicornelius]

Area

Notification Service / Reliability

Complexity

Medium

File(s)

notification-service/src/listener.ts (fetchEvents, lines ~100-141; poll, lines ~166-203)

Problem

fetchEvents wraps server.getEvents(...) in its own try/catch and swallows any error, returning [] with only a console.error. Back in poll(), the caller has no way to know the fetch failed — it just sees zero events and unconditionally calls setLastLedger(latestLedger.sequence). So any transient RPC error while fetching events (as opposed to getLatestLedger, which correctly propagates to the outer catch and skips the cursor update) causes the cursor to jump past that ledger range anyway, permanently losing every ScoreChanged event that occurred in it. This is a different, unguarded failure path from the one exercised by the existing reconnect test, which only fails getLatestLedger.

Scope

In:

• Change fetchEvents to signal failure to the caller (rethrow or return a sentinel) so poll() skips setLastLedger on a failed fetch.

Out:

• Retry/backoff policy design for RPC calls in general.

Acceptance Criteria

• A getEvents rejection prevents setLastLedger from being called for that poll cycle
• The next poll retries the same startLedger instead of skipping ahead
• A test simulating getEvents throwing (distinct from getLatestLedger throwing) asserts the cursor did not advance

[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