Skip to content
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

Closed

Conversation

michaelfig
Copy link
Contributor

@michaelfig michaelfig commented May 11, 2021

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.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

@tac0turtle
Copy link
Member

tac0turtle commented May 20, 2021

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.

@tac0turtle tac0turtle closed this May 20, 2021
@michaelfig
Copy link
Contributor Author

@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.

@tac0turtle
Copy link
Member

Yea, feel free to reopen. Glad to see there is a design to move forward with.

@michaelfig
Copy link
Contributor Author

Yea, feel free to reopen. Glad to see there is a design to move forward with.

I don't see a button to reopen this PR. Could you please do it for me?

Screen Shot 2021-05-22 at 2 01 39 PM

@github-actions
Copy link
Contributor

github-actions bot commented Jul 8, 2021

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.

@github-actions github-actions bot added the stale label Jul 8, 2021
@michaelfig
Copy link
Contributor Author

Hi @JimLarson, can you please review this change?

@michaelfig michaelfig marked this pull request as ready for review July 8, 2021 04:34
Copy link
Contributor

@technicallyty technicallyty left a 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()...)
Copy link
Contributor

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
Copy link
Contributor

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 {
Copy link
Contributor

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 ?

@aaronc aaronc added the S:needs architecture review To discuss on the next architecture review call to come to alignment label Aug 6, 2021
@aaronc
Copy link
Member

aaronc commented Aug 6, 2021

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.

@michaelfig
Copy link
Contributor Author

This definitely would need to be discussed in an architecture call. I have proposed #9656 as an explicit way to have event hooks.

@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 x/bank module. I'd be very happy if something more robust and coherent could be arrived at, and then Agoric would transition our uses of this PR to that new thing, whatever it is.

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.

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!

@github-actions
Copy link
Contributor

github-actions bot commented Oct 9, 2021

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.

@github-actions github-actions bot added the stale label Oct 9, 2021
@tac0turtle
Copy link
Member

@michaelfig is it okay we close this and work on event hooks? It does not seem like this will be merged.

@github-actions github-actions bot removed the stale label Oct 14, 2021
@michaelfig michaelfig closed this Oct 14, 2021
@robert-zaremba
Copy link
Collaborator

One question: is anyone using this approach in a fork?

@michaelfig
Copy link
Contributor Author

One question: is anyone using this approach in a fork?

Agoric is in devnet and for a future mainnet phase.

@robert-zaremba
Copy link
Collaborator

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.
Looking forward for seeing people who will like to contribute

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S:needs architecture review To discuss on the next architecture review call to come to alignment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants