Telegram (ask questions / claim the issue here first): https://t.me/+DOylgFv1jyJlNzM0
Labels: backend, testing, Stellar Wave
The exact code path behind the data-loss bug has no test.
tests/soroban-event-worker.test.ts covers idempotency/dedup and the happy-path replay, but not the failure branch in fetchAndProcessEvents where one event throws, the batch keeps going, and a later cursor still gets persisted. That's the path that drops events, and right now nothing exercises it.
What the fix has to hold to
- the test drives a real mixed batch: one handler rejects, a later one resolves
- it pins the behavior we actually want (cursor not advanced past the failure, good events written once)
Done when
Where to start
backend/tests/soroban-event-worker.test.ts, referencing backend/src/workers/soroban-event-worker.ts. Real Soroban RPC integration is out of scope, keep it mocked. Note this test will likely fail until the underlying cursor bug is fixed, which is fine and kind of the point.
Labels:
backend,testing,Stellar WaveThe exact code path behind the data-loss bug has no test.
tests/soroban-event-worker.test.tscovers idempotency/dedup and the happy-path replay, but not the failure branch in fetchAndProcessEvents where one event throws, the batch keeps going, and a later cursor still gets persisted. That's the path that drops events, and right now nothing exercises it.What the fix has to hold to
Done when
IndexerState.lastCursoris NOT advanced beyond the failed eventWhere to start
backend/tests/soroban-event-worker.test.ts, referencingbackend/src/workers/soroban-event-worker.ts. Real Soroban RPC integration is out of scope, keep it mocked. Note this test will likely fail until the underlying cursor bug is fixed, which is fine and kind of the point.