I was looking around for the source of an off-by-one error and this came up as a possible problem since worker state is modified (nextLocalEventNumber is incremented) for an event that may then be considered a duplicate. However, this doesn't actually ever happen (AFAICT) in practice when adding an event via a worker (the same function is used to add the genesis event without a worker), and if you force it to happen, it happily carries on without a problem. So this fix did not the solve the problem I was looking into.
Regardless, I think we should only be ignoring the duplicate when it is for the genesis event (a failed ledger node creation attempt occurred and we can try again later). I don't see any reason for a duplicate error to occur on an up and running node and we should throw if this happens instead of allowing potentially bad state (even if it doesn't seem fatal) to get into the system.
I was looking around for the source of an off-by-one error and this came up as a possible problem since worker state is modified (
nextLocalEventNumber
is incremented) for an event that may then be considered a duplicate. However, this doesn't actually ever happen (AFAICT) in practice when adding an event via a worker (the same function is used to add the genesis event without a worker), and if you force it to happen, it happily carries on without a problem. So this fix did not the solve the problem I was looking into.Regardless, I think we should only be ignoring the duplicate when it is for the genesis event (a failed ledger node creation attempt occurred and we can try again later). I don't see any reason for a duplicate error to occur on an up and running node and we should throw if this happens instead of allowing potentially bad state (even if it doesn't seem fatal) to get into the system.