[Merged by Bors] - refuse old proposals from gossip #5020
Conversation
countvonzero
requested review from
dshulyak,
fasmat and
poszu
as code owners
Codecov Report
@@ Coverage Diff @@
## develop #5020 +/- ##
=========================================
- Coverage 77.1% 77.1% -0.1%
=========================================
Files 254 254
Lines 30350 30363 +13
=========================================
+ Hits 23426 23436 +10
- Misses 5405 5408 +3
Partials 1519 1519
|
| @@ -262,6 +262,11 @@ func (h *Handler) handleProposal(ctx context.Context, expHash types.Hash32, peer | |||
| preGenesis.Inc() | |||
| return fmt.Errorf("proposal before effective genesis: layer %v", p.Layer) | |||
| } | |||
| if p.Layer < h.clock.CurrentLayer() { | |||
| // old proposals have no use for the node | |||
There was a problem hiding this comment.
in this case the enclosed ballot should be fetched via sync, if not already.
There was a problem hiding this comment.
another option is to save the ballot only
There was a problem hiding this comment.
what do you think about maintaining variable that is updated by block generator after it is done with this layer?
defaults to current layer on startup, but it will allow to stop accepting proposals earlier
There was a problem hiding this comment.
it's a good idea. i chose to use mesh.ProcessedLayer() to be the threshold for the following reasons
- it's updated every time a block is generated, optimistically or not
- hare can terminate out of order, so block can be generated out of order as well in the non-optimistic case
- proposal handler already have mesh interface ready to use
| @@ -262,6 +262,11 @@ func (h *Handler) handleProposal(ctx context.Context, expHash types.Hash32, peer | |||
| preGenesis.Inc() | |||
| return fmt.Errorf("proposal before effective genesis: layer %v", p.Layer) | |||
| } | |||
| if p.Layer < h.clock.CurrentLayer() { | |||
| // old proposals have no use for the node | |||
There was a problem hiding this comment.
what do you think about maintaining variable that is updated by block generator after it is done with this layer?
defaults to current layer on startup, but it will allow to stop accepting proposals earlier
|
btw i didn't notice that all old proposals are deleted during protocol runtime https://github.com/spacemeshos/go-spacemesh/blob/develop/sql/proposals/proposals.go#L190 . the function looks like that it is limited for the layer this was visible in write metrics. so it was somewhat risky
|
yes. this was risky. i made the following change
|
|
bors try |
tryBuild succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
|
bors merge |
## Motivation there are a lot of old proposals floating in the gossip network. deleting old proposals in #4993 forced the node to process/save these old proposals repeatedly ## Changes - refuse proposals older than current layer - add metrics/log for time it takes to delete proposals
|
Build failed: |
|
bors merge |
## Motivation there are a lot of old proposals floating in the gossip network. deleting old proposals in #4993 forced the node to process/save these old proposals repeatedly ## Changes - refuse proposals older than current layer - add metrics/log for time it takes to delete proposals
|
Build failed: |
|
bors merge |
## Motivation there are a lot of old proposals floating in the gossip network. deleting old proposals in #4993 forced the node to process/save these old proposals repeatedly ## Changes - refuse proposals older than current layer - add metrics/log for time it takes to delete proposals
|
Pull request successfully merged into develop. Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
bors
bot
changed the title
## Motivation there are a lot of old proposals floating in the gossip network. deleting old proposals in #4993 forced the node to process/save these old proposals repeatedly ## Changes - refuse proposals older than current layer - add metrics/log for time it takes to delete proposals
Motivation
there are a lot of old proposals floating in the gossip network.
deleting old proposals in #4993 forced the node to process/save these old proposals repeatedly
Changes