[Bug]Event cache not cleared on reorg causing duplicate and inconsistent event delivery

[xxo1shine]

Software Versions

OS: Linux
JVM: Oracle Corporation 1.8.0_161 amd64
Version: 4.8.1

Expected Behavior

After a transaction is executed and events are generated, external subscription systems should receive unique finalized event data that is consistent with the chain.

Actual Behavior

In a private network deployment, when the event service is using version 0, the event cache of the old fork chain is not cleared when a chain reorg occurs.

As a result, event data from both the forked chain and the new main chain are written into the database simultaneously. External subscribers may therefore receive duplicate or inconsistent event data.

Frequency

This issue may occur whenever a chain reorganization happens and contract event solidification (finalization) is enabled.

[lxcmyf]

This looks plausible from the current event pipeline.

BlockEventLoad.load() does detect rollback and emits realtime remove events for the old branch, but it does not evict those rolled-back BlockEvent objects from BlockEventCache.

At the same time, BlockEventCache.remove(...) only deletes entries with height < solidNum, so stale fork entries at the same height or above can remain in the cache. That makes the solidified-event path a likely place for old-fork and new-main-chain data to coexist.

So I think the fix should be in the cache layer: when reorg is detected, explicitly prune the rolled-back branch from BlockEventCache before continuing solidification.

[lvs0075]

What advice would you give to users currently using the event plugin?

[lxcmyf]

Correcting my earlier note: the cache-side problem I pointed out is scoped to event.subscribe.version = 1, not version = 0.

From the current code:

• version = 1 goes through BlockEventCache / BlockEventLoad / RealtimeEventService / SolidEventService
• version = 0 stays on the older direct trigger path in Manager and does not use that event-cache pipeline

So the specific stale-cache / solidified-event duplication risk I described is a version = 1 issue. I do not see the same cache-layer mechanism on the version = 0 path.

[xxo1shine]

This looks plausible from the current event pipeline.

BlockEventLoad.load() does detect rollback and emits realtime remove events for the old branch, but it does not evict those rolled-back BlockEvent objects from BlockEventCache.

At the same time, BlockEventCache.remove(...) only deletes entries with height < solidNum, so stale fork entries at the same height or above can remain in the cache. That makes the solidified-event path a likely place for old-fork and new-main-chain data to coexist.

So I think the fix should be in the cache layer: when reorg is detected, explicitly prune the rolled-back branch from BlockEventCache before continuing solidification.

What you described is actually the logic of version 1. Version 1 does not have this problem; only version 0 has this problem.

[xxo1shine]

Hi @lxcmyf,

Thanks for the detailed report. After reviewing the code, I believe I've identified the root cause.

Root cause (version=0 path)

When event subscription uses version=0, contract events are cached in two global maps keyed by block number:

private static final ConcurrentHashMap<Long, BlockingQueue<ContractLogTrigger>>   solidityContractLogTriggerMap
private static final ConcurrentHashMap<Long, BlockingQueue<ContractEventTrigger>> solidityContractEventTriggerMap

These maps are populated when a block is processed. However, when a chain reorganization occurs and eraseBlock() is called for the orphaned block, the entries for that block number are never removed from the maps.

When the node then processes the replacement block (same height, different fork), new events are pushed into the same map key — so the queue now contains events from both the orphaned block and the replacement block.

The existing containsTransaction guard only skips duplicate events whose transaction ID already exists in the queue. If the two competing blocks at the same height happen to contain the same transaction, the event is deduplicated — but if the transactions differ, both sets of events survive and get delivered to subscribers, producing duplicate or ghost events.

Fix direction

In eraseBlock() (or the surrounding reorg handling in Manager), the map entries for the erased block's number should be explicitly cleared:

solidityContractLogTriggerMap.remove(blockNum);
solidityContractEventTriggerMap.remove(blockNum);

This ensures stale events from the orphaned block cannot accumulate alongside events from the canonical replacement block.

We will look into a proper fix. Thank you again for the investigation!

[xxo1shine]

Hi @lvs0075,

For users currently relying on the event plugin with version=0, we recommend:

1. Switch to version=1 if possible. The version=1 event subscription path does not use the global solidityContractLogTriggerMap / solidityContractEventTriggerMap caches, so it is not affected by this reorg issue.

2. If staying on version=0, implement deduplication on the consumer side. Since duplicate or orphaned events may be delivered during a reorg, your event consumer should deduplicate by (transactionId, logIndex) and only commit events once the block reaches sufficient confirmation depth.

3. Monitor block numbers. If you observe events for the same block number arriving more than once, treat it as a signal that a reorg occurred and re-validate the events against the canonical chain.

We are working on a fix to clear the map entries in eraseBlock() so that orphaned events are discarded during reorg. We will update this issue once a fix is available.