-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
types: Emit tags from BeginBlock/EndBlock #2747
types: Emit tags from BeginBlock/EndBlock #2747
Conversation
71fbcd7
to
4f293d9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🍓 🍌 🥛
Thanks for contributing to Tendermint! This is a good start. However, I am not confident about putting begin/end block results into EventNewBlock.
78c16ef
to
8d15671
Compare
I've addressed some design comments and rebased on the latest develop branch. PTAL. |
It seems that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely a step in the right direction! A few comments though
317353b
to
441a0f4
Compare
Rebased on latest develop, updated docs and pending changelog. PTAL. |
Codecov Report
@@ Coverage Diff @@
## develop #2747 +/- ##
===========================================
+ Coverage 62.16% 62.18% +0.01%
===========================================
Files 212 212
Lines 17227 17278 +51
===========================================
+ Hits 10710 10745 +35
- Misses 5614 5626 +12
- Partials 903 907 +4
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🍇 🍷
441a0f4
to
ea14968
Compare
All comments should be addressed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💎
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is the design we should go with - it feels a little adhoc to just add these tags to the NewBlock events. From looking at the fire event sequence for a block:
func fireEvents(logger log.Logger, eventBus types.BlockEventPublisher, block *types.Block, abciResponses *ABCIResponses) {
eventBus.PublishEventNewBlock(types.EventDataNewBlock{block})
eventBus.PublishEventNewBlockHeader(types.EventDataNewBlockHeader{block.Header})
for i, tx := range block.Data.Txs {
eventBus.PublishEventTx(types.EventDataTx{types.TxResult{
Height: block.Height,
Index: uint32(i),
Tx: tx,
Result: *(abciResponses.DeliverTx[i]),
}})
}
abciValUpdates := abciResponses.EndBlock.ValidatorUpdates
if len(abciValUpdates) > 0 {
// if there were an error, we would've stopped in updateValidators
updates, _ := types.PB2TM.ValidatorUpdates(abciValUpdates)
eventBus.PublishEventValidatorSetUpdates(
types.EventDataValidatorSetUpdates{ValidatorUpdates: updates})
}
}
it feels more natural to follow the same order as the ABCI execution, by firing a BeginBlock event before, and an EndBlock event after, the set of tx events. Note we are already firing a ValidatorUpdates event after the txs, which could be subsumed by an EndBlock one.
Thoughts?
} | ||
return result | ||
} | ||
|
||
func (b *EventBus) PublishEventNewBlock(data EventDataNewBlock) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it maybe be better to have independent subscription events for BeginBlock and EndBlock, rather than stuffing them in with NewBlock/NewBlockHeader like this?
@@ -54,11 +55,17 @@ func RegisterEventDatas(cdc *amino.Codec) { | |||
|
|||
type EventDataNewBlock struct { | |||
Block *Block `json:"block"` | |||
|
|||
ResultBeginBlock abci.ResponseBeginBlock `json:"result_begin_block"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we treat these like we treat transactions, as independent events, with EventDataBeginBlock and EventDataEndBlock?
What are the use cases for getting just this data - is it more useful with the block itself or with other results tags from the block?
Well, transaction tags are added to a transaction event, not to a separate event? What would the hypothetical BeginBlock/EndBlock events contain? Only the ABCI responses? This seems strange, what if you (as a subscriber) want the block or the block header, then you need to maintain additional state? |
ea14968
to
2564ec0
Compare
This commit makes both EventNewBlock and EventNewBlockHeader emit tags on the event bus, so subscribers can use them in queries. This is a BREAKING change due to adding a field to the ABCIResponses structure which is persisted to disk.
2564ec0
to
b7aa527
Compare
Right, they're part of the ResponseDeliverTx - I think it makes sense to have a single event per abci response.
Note we have a validator update event - I think we should fold that into an EndBlock event, and we can include the tags there. If you really think it's necessary, we can put the header in the EndBlock event too, but that might be over kill. We can avoid the BeginBlock event for now by putting its response in the NewBlock and NewBlockHeader events, like you've done. I think that makes sense. My main gripe here is having the EndBlock event stuff distinct from the existing EventValidatorSetUpdates. I think we need to consolidate those. |
Is that right? I'm not sure actually. Will some folks only want to subscribe to the ValidatorUpdates? Or is it fair to say that if you want to know about updates, subscribe to the EndBlock and check every time? I think it would be kind of nice for the Event system to as much as possible match the ABCI structure, unless there are really strong reasons otherwise. We should probably write an ADR about all this ... |
Last point: thanks for noting this is a breaking upgrade on the state. Appreciate it. We can minimize the impact of that by writing a small upgrade tool that will allow people to upgrade their existing State. It can even be an automatic part of the node, now that we have the software version built into the state! Do you want to take this on? Thanks! |
So I switched the field order as you suggested. Not sure how Amino serializes things, does it assign field tags based on field order? In this case the change may already be non-breaking now? |
So the NewBlock/NewBlockHeader events would only contain responses and tags from BeginBlock and EventValidatorSetUpdates would only contain responses and tags from EndBlock? For me, either would be fine actually as long as we can get the block height corresponding to the emitted tags together with the event(s). @t-bast would this work for your use cases? |
Same for me, either would be fine. Thanks guys! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I think this is fine. Thanks all!
* develop: types: Emit tags from BeginBlock/EndBlock (tendermint#2747) Fix fast sync stack with wrong block tendermint#2457 (tendermint#2731) It's better read from genDoc than from state.validators when appHeight==0 in replay (tendermint#2893) update encoding spec (tendermint#2903) return back initially allowed level if we encounter allowed key (tendermint#2889) Handling integer IDs in JSON-RPC requests -- fixes tendermint#2366 (tendermint#2811) # Conflicts: # blockchain/reactor_test.go # blockchain/store_test.go # node/node_test.go # types/events.go
See #1571.
This may need some discussion if the design seems sound. Note that this breaks the on-disk format due to including the
BeginBlock
field in theABCIResponses
structure.