feat(chain-simulator): make block generation configurable with AUTO_GENERATE_BLOCKS - #186
Merged
Merged
Conversation
Add InvalidConfigValue error class and validation in should_generate_blocks to catch typos like 'ture' instead of silently disabling blocks. Unrecognized values now raise an explicit error. Add import-cycle clarification comment explaining why the helper lives in providers.py rather than config.py.
When AUTO_GENERATE_BLOCKS=false, the polling loop was busy-polling at 0.001s (chain-simulator refresh period). This was safe when generate_blocks_until_tx_completion ran first, but skipping that creates thousands of proxy requests per transaction. Introduce MIN_TX_REFRESH_PERIOD=0.2 and clamp the refresh period in the non-generating path to avoid tight busy-polling against the simulator.
When AUTO_GENERATE_BLOCKS=false, Phase 5 of ChainSimulatorSetTokenBalanceStep was waiting only for the metachain to advance. However, ESDT balances are stored on the receiver's user shard, and metachain/user-shard production are not synchronized. A single metachain block does not prove the receiver's shard has committed the written state, risking stale reads. Now wait for all user shards (0..num_shards-1) plus the metachain so the set_address_state writes are committed everywhere before returning.
The startup path unconditionally calls generate_blocks_until_epoch(2), even though block generation is otherwise gated by AUTO_GENERATE_BLOCKS. Clarify that this is intentional: the bundled simulator is always started in manual mode, this bootstrap runs before any user scene, and the auto-generate case targets an external simulator not started via this command.
Add tests for both branches of send_and_wait_for_result: the default generates-blocks-then-returns path, and the new polls-with-clamped-period path when AUTO_GENERATE_BLOCKS=false. Verifies that generate_blocks_until_tx_completion is called in the first case and not in the second, and that the refresh period is clamped to MIN_TX_REFRESH_PERIOD to prevent busy-polling.
…TE_BLOCKS Test that should_generate_blocks raises InvalidConfigValue on unrecognized config values (e.g. typos like 'ture'). Also update existing tests to restore the prior config value instead of hardcoding 'true', improving test isolation.
Patch get_network_status at its usage site (mxops.execution.utils) instead of the base class, making the mock less fragile. Restore the prior AUTO_GENERATE_BLOCKS value in teardown instead of hardcoding 'true', improving test isolation and eliminating cross-test config contamination.
Update test_step_auto_generate_blocks_disabled_waits to verify that Phase 5 waits on all user shards (0, 1, 2) plus the metachain when not generating blocks, ensuring the set_address_state writes are committed everywhere. Restore prior config value in teardown for proper test isolation.
Document in the Changed section that chain-simulator block production is now gated by AUTO_GENERATE_BLOCKS flag. Transaction waits, WaitStep, and set-token-balance only drive blocks when enabled (the default); when disabled, MxOps waits for the auto-producing simulator instead with a clamped polling rate.
Allow users to control whether MxOps drives chain-simulator block production. Set AUTO_GENERATE_BLOCKS=false to point MxOps at a simulator started with auto-generate-blocks enabled, where MxOps waits for blocks instead of forcing them. Default is true, preserving today's behavior. Adds should_generate_blocks helper in providers.py that gates block generation calls, and documents the feature in chain_simulator.md.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Introduce an
AUTO_GENERATE_BLOCKSconfig option to control whether MxOps drives chain-simulator block production. Users can now point MxOps at a simulator started withauto-generate-blocksenabled by settingAUTO_GENERATE_BLOCKS=false, where MxOps behaves like on other networks: it polls/waits for blocks instead of forcing them. Default istrue, preserving today's behavior.Changes
AUTO_GENERATE_BLOCKSconfig option (defaulttrue) to the[CHAIN_SIMULATOR]section, validated so malformed values raise an explicit error instead of silently disabling block generationshould_generate_blocks()helper inproviders.pythat gates block production on the network + flagsend_and_wait_for_result): drives blocks until completion only when enabled; otherwise polls at a clamped refresh rate to avoid busy-pollingWaitStep(for_blocks=N): generates blocks or waits for them depending on the flagChainSimulatorSetTokenBalanceStepPhase 5: commits state via block generation when enabled, otherwise waits on every user shard and the metachain so the balance writes are committed where they liveTesting
All 306 unit tests pass:
bash scripts/launch_unit_tests.sh✅bash scripts/check_python_code.sh(bandit, flake8, ruff, pylint ≥ 9.5) ✅Test coverage includes
should_generate_blocks()across all branches (other network, default-on, explicitly-off, missing option, malformed value), bothsend_and_wait_for_resultpaths (generates vs. polls with clamp),WaitStepin auto mode, andChainSimulatorSetTokenBalanceStepPhase 5 multi-shard waits.Configuration:
To use with an auto-producing simulator:
Backward Compatibility
Fully backward compatible. Default
truepreserves existing behavior. User configs without the option default totrue, so no action is required for existing users.