-
Notifications
You must be signed in to change notification settings - Fork 36
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: expose config.IsSealed
#414
feat: expose config.IsSealed
#414
Conversation
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 there a way to only call this once in the multiplexer and then never call it in the application?
No because the v2 state machine needs to work independently of the multiplexer. There are at least these two combinations:
|
if the multiplexer is the only thing that calls seal, and it gets ran no matter which state machine is picked, then is this true? its not really worth spending a lot of time on, but if there are common initializing things, then I think refactoring them into the multiplexer could be beneficial. Like, afaiu, we're not stuck calling |
We can do this for the v3.0.0 binary but the v2.x.x binaries need to be able to run without the multiplexer so they have to invoke We could make a 2.x.x release and inform users that they can't run it independently and it must be run via a multiplexer but that would be a breaking change and pretty confusing for users. We could also make a 2.x.x release that exposes a variant of |
thanks for explaining 🙂, makes sense |
3562f46
into
celestiaorg:release/v0.46.x-celestia
Expose
config.IsSealed
so that we can check it before invoking seal on it from the v2 and v3 state machine. We can remove this as soon as Cosmos SDK removes the global singleton config.