Jon Zlotnik

got too excited when #3449 merged 🤦 I thought this issue just failed to close automatically.

I can think of two solutions: (1) Wait on multiple rounds at a time. Maybe always wait on the next 2 rounds, each in their own goroutine? And cancel the...

To elaborate on the original issue: The consensus process only moves forward if `case

related to: https://github.com/spacemeshos/go-spacemesh/issues/1331 see my comment explaining the root cause in detail https://github.com/spacemeshos/go-spacemesh/issues/1331#issuecomment-1254016222

As a quick fix, we can just return early here from the queued task if `updateLatestLayer` fails. https://github.com/spacemeshos/go-spacemesh/blob/bb0057417ae6c0929992ef4403083fb981a84a63/hare/broker.go#L392-L394 Since `updateLatestLayer` only ever used in the anonymous register functions that get...

ALSO, whoever fixes this bug needs to make this method atomic: https://github.com/spacemeshos/go-spacemesh/blob/bb0057417ae6c0929992ef4403083fb981a84a63/hare/broker.go#L328-L337 - [ ] **The `getLatestLayer` and `setLatestLayer` are each protected by a lock, but `updateLatestLayer` isn't.**

A more robust option could be to have an allowed-early-delta that is adjusted based on expected network delay. This way, in tests, as long as the message is received within...

Currently, all messages are allowed up to one layer before they’re supposed to be sent Validate the message contextually: https://github.com/spacemeshos/go-spacemesh/blob/0cb3732b0796ed442366f39ef8cf3909a0c2b48d/hare/broker.go#L246-L266 If message is for the next layer, it's early, otherwise...

The "bug" in late registration is just a queue that isn't processed in time. (I presume this happens only when running hare with small round durations, but no further details...

See comments on #3287 for network security. However this will need further safeguards for accumulation of data in memory that either doesn't get put into a message or is spread...