Telegram: https://t.me/+DOylgFv1jyJlNzM0
Why this matters
In backend/src/workers/soroban-event-worker.ts, every event handler (handleStreamCreated, handleTokensWithdrawn, handleFeeCollected, etc.) checks tx.streamEvent.findUnique({ where: { transactionHash_eventType } }) and skips/upserts to avoid duplicates on replay. But handleStreamPaused and handleStreamResumed call tx.streamEvent.create(...) directly with no dedup guard.
Given the @@unique([transactionHash, eventType]) constraint in schema.prisma, a replay (/v1/admin/indexer/replay) of a ledger containing a pause/resume will throw a unique-constraint error mid-transaction for those handlers, which is inconsistent with the restart-safe behaviour of the rest of the worker (#381).
Acceptance criteria
Files to touch
backend/src/workers/soroban-event-worker.ts (handleStreamPaused, handleStreamResumed)
Out of scope
Telegram: https://t.me/+DOylgFv1jyJlNzM0
Why this matters
In
backend/src/workers/soroban-event-worker.ts, every event handler (handleStreamCreated,handleTokensWithdrawn,handleFeeCollected, etc.) checkstx.streamEvent.findUnique({ where: { transactionHash_eventType } })and skips/upserts to avoid duplicates on replay. ButhandleStreamPausedandhandleStreamResumedcalltx.streamEvent.create(...)directly with no dedup guard.Given the
@@unique([transactionHash, eventType])constraint inschema.prisma, a replay (/v1/admin/indexer/replay) of a ledger containing a pause/resume will throw a unique-constraint error mid-transaction for those handlers, which is inconsistent with the restart-safe behaviour of the rest of the worker (#381).Acceptance criteria
handleStreamPausedandhandleStreamResumeduse the same find-then-upsert-with-skip pattern as the other handlersFiles to touch
backend/src/workers/soroban-event-worker.ts(handleStreamPaused,handleStreamResumed)Out of scope