Closed mplsgrant closed 2 weeks ago
There is a specific reason this was removed: it requires ALL nodes' mempools and blockchains are exactly the same. That might make sense for bitcoin core test networks but it will be vary common in Warnet to have network divisions or inconsistent mempool policies. It is a default callback for generate()
so it may cause infinite waits in some scenarios.
Unless I'm missing something @josibake @mplsgrant I think we should consider reverting this. Perhaps we need to add a test with a split network that would fail if this patch were merged.
Long term: I think since our last call its made me think that scenarios may be our primary interface with warnet users. In that case, we may want to just consider the bitcoin test framework a placeholder and actually write our own scenario framework so we dont have to hack the bitcoin core framework to little bits.
consider reverting this
Ok second thought, this is too harsh. But we should make sure all the self.generate()
calls in scenarios use a dummy to stub out the sync_fn()
argument.
And I still think we should plan long term on replacing the bitcoin test framekwork
Ok second thought, this is too harsh. But we should make sure all the self.generate() calls in scenarios use a dummy to stub out the sync_fn() argument.
Agreed
And I still think we should plan long term on replacing the bitcoin test framekwork
I am curious to hear more about this idea. Coming from the outside, it seems like lots of people "think" in terms of the bitcoin test framework. So, supporting it gets us lots of tests that people might code up on a whim and want to run.
@mplsgrant starting dsicussion here: https://github.com/bitcoin-dev-project/warnet/discussions/364
Issue
Calling
sync_all()
from within a scenario does nothing.Cause
WarnetTestFramework
explicitlypass
es onsync_all()
.Solution
Enable
sync_all()
by removing it fromWarnetTestFramework
which exposes it via the base classBitcoinTestFramework
.