[Backend] Event indexer has no cross-instance lock and can double-process ledger ranges

[grantfox-oss]

Telegram (ask questions / claim the issue here first): https://t.me/+DOylgFv1jyJlNzM0

Why this matters

src/services/eventIndexer.ts persists last_indexed_ledger but two instances can both read the same cursor and fetch the same range; only the ON CONFLICT DO NOTHING insert prevents duplicate rows, wasting RPC calls and risking duplicate webhook/notification dispatch which happen before the conflict is known.

Acceptance criteria

• Guard each indexer poll cycle with a Postgres advisory lock or Redis lock so only one instance advances the cursor at a time
• Ensure side effects (webhook dispatch, notifications) only fire for rows this instance actually inserted
• Confirm a restarted instance still resumes cleanly from the persisted cursor
• Add a test simulating two concurrent poll cycles processing without duplicate dispatch

Files to touch

• src/services/eventIndexer.ts
• src/services/indexerManager.ts

Out of scope

• Switching off polling to streaming
• Reorganizing the indexer_state schema

[Kaycee276]

Hi maintainer can i work on ths issue

[nonsobethel0-dev]

I'd like to take on this issue.

I have experience building backend systems for blockchain applications, including event-driven architectures that synchronize on-chain activity with off-chain services. I've worked on projects involving Soroban smart contracts, webhook pipelines, notification systems, and event indexing, where correctness and idempotency are critical.

For this issue, I would implement a distributed locking mechanism (Postgres advisory lock or Redis lock, depending on the project's existing infrastructure) to ensure only a single indexer instance can advance the cursor during each polling cycle. I would also update the processing flow so that webhooks and notifications are only dispatched for records successfully inserted by the active worker, preventing duplicate side effects when multiple instances are running.

Additionally, I would verify clean recovery from persisted checkpoints after restarts and add concurrency-focused tests that simulate multiple pollers attempting to process the same ledger range, ensuring duplicate dispatches cannot occur.

My background in backend development and blockchain infrastructure makes me comfortable working on event ingestion, locking strategies, idempotent processing, and fault-tolerant systems. I'd be happy to contribute a robust solution that satisfies all acceptance criteria.

[grantfox-oss]

🦊 GrantFox — @nonsobethel0-dev has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #5)
2. Your PR will be reviewed by the LabsCrypt maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@nonsobethel0-dev's PR #31 was approved and merged by @ogazboiz.

🏆 @nonsobethel0-dev: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (153 total points). Track your full progress on GrantFox.

👏 Great work, @nonsobethel0-dev! Keep contributing to LabsCrypt.