Requesting a block after receiving an event about it on the observer might result it the node not having processed it yet

[jferrant]

There is a discrepency between the burn block processed and broadcasted by event observer and the node updating its peer info state. Saw some signer errors as a result:

08:19:26.594 Burn block 897996 arrives at signer -> Signer queries node for its peer info 08:19:26.623 Node responds with outdated Peer Info with burn block 897995 08:19:26.624 Signer fails to handle burn block resorting in it having an oudated miner view 08:19:35.290 Runloop: Synchronized full burnchain up to height 897996 (at this point peer info should return the correct info)

It would be nice if we could ensure that if a burn block is propogated, it has been processed byt he node. This of course could slow things down though and am not sure it should even be fixed.}

[aldur]

Notes from the daily sync:

For context: the node emits the burn block event before it commits the block to the DB. This is one of the guarantees of the event observer.

So if you receive the event and then immediately query the node it will look like the node hasn't received it yet (as in the issue).

This is unlikely to happen due to how the P2P stack (and locking works), but can happen.

To deal with this with the signer we might need to have pending state updates (after the event, switch state to pending and only update the state after fetching data from the node, similarly to how the node's local state machine handles the events).

[aldur]

Mid-term, we could think that different consumer of events might have different preferences (e.g. only be notified after the Stacks node has processed the event).

[jferrant]

@aldur this is actually handled correctly on the signer side by @kantai's logic already See https://github.com/stacks-network/stacks-core/blob/233927f9397a5a89cc785553d084f891d8194504/stacks-signer/src/v0/signer_state.rs#L499-L509

This really is a red herring that it happened during the stall. It contributed to the misaligned view of the signer but the true issue is the flip flopping between miner view points.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.