-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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: Add PrepareCheckState
and Precommit
callbacks
#14860
feat: Add PrepareCheckState
and Precommit
callbacks
#14860
Conversation
baseapp/abci.go
Outdated
// empty/reset the deliver state | ||
app.deliverState = nil | ||
|
||
if app.commiter != nil { | ||
app.commiter(app.checkState.ctx) | ||
} | ||
|
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.
Change potentially affects state.
Call sequence:
(*github.com/cosmos/cosmos-sdk/baseapp.BaseApp).Commit (baseapp/abci.go:426)
Hello! I have some questions:
|
Hey @facundomedica. Great questions!
Currently we are putting data related to our orderbook in the
This can't be done in
Yes. Currently modules can set data in the
I can't think of any other use-cases other than our own. Our own use-case may also be unique given that we perform a high number of state writes during It's very possible that this may be something unique to our own use-case, and if that is true then we can continue to maintain a lightweight fork that includes this change for the time being. |
Is something like PrepareCheckState more explicit here, with Commit I would think modules can commit other db together with the main db. |
Yes I agree with your thinking here. It's not clear based on the current implementation that the state within the context is the
No this is not a |
So what I gather from this as the gist is that you want a way for all validators to modify the CheckTx state prior to the next block being called, as opposed to it being set to the resulting state after Commit as it is today? If so, I don't immediately see anything wrong with this and I'm not opposed. I think clear and clean APIs with sufficient documentation would be enough for me to give a green light. I don't want to encourage teams to maintain their own forks when it's not necessary :) |
@alexanderbez +1 here, this would be helpful for our evm |
Yeah sounds good. Feel free to push it over the finish line 👍 |
@alexanderbez would you be open to moving the hook to BEFORE the multistore is committed. Our use case actually needs access to the transient store from the block. Pros and cons to both I guess. Unless we add PreCommit() PostCommit()? Seems like @prettymuchbryce needs it after the commit though. So maybe this needs a broader discussion |
@itsdevbear can you further elaborate on your use-case? The original proposal was to modify CheckTx after commitment. How does yours differ? |
@itsdevbear We recently had a similar requirement in our codebase as well, so we decided to add a second callback for I wonder if there would be appetite to include both of these upstream. We can help clean things up and move both callbacks into this PR.
@alexanderbez I'm curious what other documentation we should be thinking about other than just the Godoc comments. For example this section of the documentation, or other places I may be missing. |
Our use case is to dump data from the previous block to an off chain store for indexing. Right now we are doing it in end block, which works but it's technically possible for the previous block to error out. Doing it on commit feels much safer. But we can't do it before the ctx is reset. Since we were thinking storing this data in a transient store during the block and dumping to an off chain disk at the end. |
even if it error out, it'll be replayed eventually, so probably not a big deal? |
@itsdevbear if it's for indexing, why don't you just use the state streamer. That's what it was designed for. @prettymuchbryce I would say any baseapp or ABCI docs should have mention of this 👍 |
yeah @alexanderbez that was the other thing we were thinking. Will investigate that path as well. Ty ser either way I think pre and post still useful here. |
@itsdevbear @prettymuchbryce would you be willing to come on the community call next week to discuss this feature sync so we can move this forward |
@tacoturtle definitely down, we can also chat about: #14660 it's a relatively a critical for us one for us. Can you send me the info / send a cal recurring cal invite? |
I am down. Can you send me an invite? |
@prettymuchbryce are you open to adding the post-hook in this PR as you did with the pre-hook, so we can achieve the needs of both teams? Happy to review and approve. |
5066667
to
cda4b81
Compare
baseapp/abci.go
Outdated
// Commit. Use the header from this latest block. | ||
app.setState(runTxModeCheck, header) | ||
|
||
if app.precommiter != nil { | ||
app.precommiter(app.deliverState.ctx) | ||
} | ||
|
||
// empty/reset the deliver state | ||
app.deliverState = nil | ||
|
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.
Change potentially affects state.
Call sequence:
(*github.com/cosmos/cosmos-sdk/baseapp.BaseApp).Commit (baseapp/abci.go:452)
@@ -456,14 +456,18 @@ func (app *BaseApp) Commit() abci.ResponseCommit { | |||
header := app.deliverState.ctx.BlockHeader() | |||
retainHeight := app.GetBlockRetentionHeight(header.Height) | |||
|
|||
if app.precommiter != nil { |
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.
@itsdevbear Was curious if this is where you envisioned this being invoked. At this point, your TransientStore will not have been cleared yet.
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.
This makes sense to me. If we are passing in the ctx without nuking it, I don't think it really matters where it happens.
As far as I can tell the remaining CI failures in this PR are not related to my changes. Let me know if I am missing something. |
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.
lgtm!
As far as I can tell the remaining CI failures in this PR are not related to my changes. Let me know if I am missing something.
Yes, these CI failures are unrelated.
@prettymuchbryce we've been using this branch, has been good so far. |
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.
LGTM. This might change a bit with the implementation of abci 1.0, but I don't foresee big changes given that Commit() will remain pretty much the same iirc
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.
utACK. we can do a follow up pr to add docs
⚡️🎉 |
Tagged cosmossdk.io/api v0.4.1 with this. |
Pulled sdk main into polaris, it works great. Thanks @prettymuchbryce for pushing this across. |
Description
This PR introduces optional
PrepareCheckState
andPrecommit
callbacks. It allows modules to optionally include these methods.These callbacks are similar to the existing callbacks for
BeginBlock
andEndBlock
that modules may register, but slightly simpler they accept no arguments besides ansdk.Context
, and they have no return values.Precommit
- Invoked duringBaseApp.Commit()
before thedeliverState
is written to therootMultiStore
. It is invoked with thedeliverState
. This could be useful for data/metrics pipelines that want to flush data to some external source, immediately before thedeliverState
for the block is written, and before anyTransientStore
within thedeliverState
has been reset.PrepareCheckState
- Invoked duringBaseApp.Commit()
after thedeliverState
has been written to therootMultiStore
, thedeliverState
has been emptied/reset, and thecheckState
has been set with the new block header. Invoked with thecheckState
of the next block. dYdX has introduced this functionality into our own fork as a way to prepare thecheckState
with some data immediately after the block has been committed.Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change