fix(apps/hermes): fix duplicate events for processed slots

[cctdaniel]

Fix Duplicate Events for Processed Slots

Problem

The application was experiencing an issue where multiple events could be sent for the same slot under certain conditions:

1. When a slot was processed out of order (e.g., slot 100, then 101, then 100 again), the system would send both a New event and an OutOfOrder event for the same slot.
2. During concurrent processing of updates for the same slot, race conditions could lead to duplicate events being sent.

This resulted in downstream consumers (like SSE clients) receiving redundant events, which could cause unnecessary processing and potential bugs.

Solution

We implemented a more efficient mechanism to ensure that only one event is ever sent per slot:

1. Modified store_wormhole_merkle_verified_message to check if a state already exists for the given slot before storing it, returning a boolean to indicate whether the state was newly stored.

2. Modified store_update to check if accumulator messages already exist for a slot before storing them, returning early if they do.

This approach leverages the existing cache mechanisms (which already have size limits) to determine if a slot has been processed before. When either a VAA or accumulator message for a slot is received again, we detect this early in the processing pipeline and return immediately, preventing duplicate processing and event generation.

This solution is more memory-efficient as it eliminates the need for an unbounded tracking set while still ensuring that each slot will only generate a single event, either New or OutOfOrder, but never both.

Testing

Two tests were added to verify the fix:

1. test_out_of_order_updates_send_single_event_per_slot: Verifies that when processing slots out of order (100 > 101 > 100), only one event is sent for each slot.
2. test_concurrent_updates_same_slot_sends_single_event: Verifies that when 100 concurrent updates for the same slot are processed, only one event is sent.

Both tests confirm that our solution effectively prevents duplicate events while maintaining the correct application state.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
api-reference	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 19, 2025 0:38am
component-library	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 19, 2025 0:38am
entropy-debugger	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 19, 2025 0:38am
insights	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 19, 2025 0:38am
proposals	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 19, 2025 0:38am
staking	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 19, 2025 0:38am

[ali-bahjati]

my recommendation is that when you call store_wormhole_merkle_verified_message (and the other one) you return something like it was there or not, and if it was there you return immediately. Those states also have a limited size to make sure they don't grow much.

[ali-bahjati]

Nice! can you bump the version before merging?