-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
feat: implement EventManager().GetABCIEventHistory() #9305
Conversation
Hey, thanks for opening this PR. It seems there are some considerations that need to be discussed prior to making a PR. There is a discussion (#8272) that touches on this. Lets continue the conversation there. |
@marbar3778 I'd like to reopen this PR and evolve it based on the thread linked above (tendermint/tendermint#5977 (comment)) where @alexanderbez and @robert-zaremba also weighed in that this design might be feasible. I know there's significantly more work to be done before this PR can be merged, but Agoric has a vested interest, and @JimLarson and I can put in the effort needed to refine it. |
Yea, feel free to reopen. Glad to see there is a design to move forward with. |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hi @JimLarson, can you please review this change? |
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.
just a couple concerns/comments - would be nice to have some tests to show it is collecting event history in a block properly
@@ -751,6 +756,7 @@ func (app *BaseApp) runMsgs(ctx sdk.Context, msgs []sdk.Msg, mode runTxMode) (*s | |||
// Note: Each message result's data must be length-prefixed in order to | |||
// separate each result. | |||
events = events.AppendEvents(msgEvents) | |||
historicalEvents = append(historicalEvents, msgEvents.ToABCIEvents()...) |
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.
does this need to be used somewhere? it looks like its collecting all the msgs events, but its not given to anything else?
ctx sdk.Context | ||
ms sdk.CacheMultiStore | ||
ctx sdk.Context | ||
eventHistory []abci.Event |
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.
is the extra field here truly necessary? im curious if this PR can work by just storing the events in the state's existing ctx event manager.
|
||
// GetEventHistory returns a deep copy of the ABCI events that have been | ||
// committed to thus far. | ||
func (em *EventManager) GetABCIEventHistory() []abci.Event { |
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.
the history is stored as a value, not a pointer - not sure if deep copy is needed here, couldn't we just return em.history
?
This definitely would need to be discussed in an architecture call. I have proposed #9656 as an explicit way to have event hooks. One issue with this approach is that there currently is no formal contract that events are part of the state machine or have any kind of breaking API guarantees. #9656 would add some explicit typing. Either way we do need to consider what the most correct way to do this is and the types of guarantees modules need to provide each other around events. |
@JimLarson would you be able to help work on this in the architecture call when it comes up, as you know what our constraints are? Essentially, this PR is the result of needing something urgently to solve a problem that otherwise would have required hacking up a modified
Agreed. The main advantage of the current PR is that it is conceptually simple and just provides additional information to modules that run later in the block. I would hope the replacement (probably more general) solution could preserve that spirit. Thanks for your attention to this! |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@michaelfig is it okay we close this and work on event hooks? It does not seem like this will be merged. |
One question: is anyone using this approach in a fork? |
Agoric is in devnet and for a future mainnet phase. |
During today architecture call we decided to move forward with a canonical event hooks implementation in the Cosmos SDK. We are more leaning to #9656 design. |
Description
Experimental PR to keep this block's event history in
EventManager()
so that message handlers and end blockers can use the events to make decisions without having to explicitly hook into other modules.Some of the initial discussion as to the general structure of the PR is at the thread at tendermint/tendermint#5977 (comment).
closes: #XXX
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes