Previously, in about 1% of the test runs (on my machine), finality was reached one Commit() too early. In #319, a curious fix is found: a slight delay after the subscription is set up, but before the first blocks are generated apparently prevents this from happening. I can't understand how this could possibly fix the problem, but since then, I could no longer reproduce it, so must be causally related.
Proposal
Find out why the reorg-resistant subscription breaks in this way and fix it, if possible. Otherwise, we might have to issue a bug report in the go-ethereum repository.
Location
backend/ethereum/subscription/resistanteventsub_test.go:TestResistantEventSub_Confirm,TestResistantEventSub_ReorgRemoveProblem
Previously, in about 1% of the test runs (on my machine), finality was reached one Commit() too early. In #319, a curious fix is found: a slight delay after the subscription is set up, but before the first blocks are generated apparently prevents this from happening. I can't understand how this could possibly fix the problem, but since then, I could no longer reproduce it, so must be causally related.
Proposal
Find out why the reorg-resistant subscription breaks in this way and fix it, if possible. Otherwise, we might have to issue a bug report in the go-ethereum repository.