feat: expose config.IsSealed

[rootulp]

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.

[evan-forbes]

Is there a way to only call this once in the multiplexer and then never call it in the application?

[rootulp]

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:

• User runs v2.0.0 binary which should invoke config.Seal()
• User runs v3.0.0 binary which has multiplexer. The multiplexer imports v2.0.0 state machine which invokes config.Seal(). The v3.0.0 state machine can not run config.Seal() but that means it isn't usable unless run via the multiplexer.

[evan-forbes]

the v2 state machine needs to work independently of the multiplexer

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 app.New, we can modify app.New to be whatever we want now because we're calling Multiplexer.New, and that function is initializing the application upon each celestia-appd start

[rootulp]

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?

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 config.Seal() themselves.

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 app.New() that is only meant to be called by the multiplexer which bypasses the config.Seal(). That seems more complicated than conditionally invoking config.Seal() from v3.

[evan-forbes]

thanks for explaining 🙂, makes sense