Start call delay hyperparameter #2315
Open
+201
−47
Conversation
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
Prompt: "make a sudo-only hyperparameter for the delay before calling start call which is hardcoded to 50400 or 7*7200 currently" This commit converts the hardcoded DurationOfStartCall constant (50400 blocks, or ~7 days) into a runtime-configurable hyperparameter called StartCallDelay that can be modified via sudo extrinsic. Changes: - Added StartCallDelay storage value with DefaultStartCallDelay type_value - Renamed DurationOfStartCall config constant to InitialStartCallDelay - Added StartCallDelaySet event for hyperparameter updates - Added get_start_call_delay() and set_start_call_delay() functions - Added sudo_set_start_call_delay() extrinsic in admin-utils (call_index 84) - Updated subnet.rs to read from storage instead of config constant - Updated runtime constant from DurationOfStartCall to InitialStartCallDelay - Updated all mock files and test usages to use new parameter name - Updated benchmarks and tests to use StartCallDelay::<T>::get() The delay can now be modified at runtime via the sudo_set_start_call_delay() extrinsic without requiring a runtime upgrade, providing more flexibility for network governance. Users can read the current value through: - Direct storage queries via state_getStorage RPC call - The get_start_call_delay() getter function for internal use - Client libraries (polkadot-js, subxt) which auto-generate storage accessors
Added test_sudo_set_start_call_delay_permissions_and_zero_delay which: 1. Verifies permission checking - non-root accounts cannot set the delay 2. Creates a subnet 3. Attempts to start it immediately - FAILS (delay not passed) 4. Sets delay to zero via sudo_set_start_call_delay() 5. Verifies StartCallDelaySet event is emitted 6. Attempts to start the same subnet again - SUCCEEDS (delay now zero) 7. Attempts to start it a third time - FAILS (already started) This test validates the key scenario: a subnet that couldn't be started due to the delay can be started after reducing the delay to zero, proving the hyperparameter change takes immediate effect. The test calls start_call three times to thoroughly verify the state transitions and confirms the proper event is emitted when the delay is changed.
open-junius
previously approved these changes
Dec 22, 2025
Contributor
open-junius
left a comment
open-junius
left a comment
There was a problem hiding this comment.
Looks good to me. Just need bump the runtime version "spec_version: 365".
and inform Roman there is a broken e2e test.
Contributor
@basfroman for awareness |
Replace all references to DurationOfStartCall with InitialStartCallDelay to match the renamed constant in the codebase. Improvements: - Updated variable names from DurationOfStartCall to InitialStartCallDelay - Updated grep checks to look for the new constant name - Updated perl replacements to modify the new constant name - Added clear error messages for all replacement failures - Added context messages explaining that codebase may have changed - Added progress indicator when applying patches - Enhanced final success message with checkmark
Eliminates code duplication by consolidating check and replace logic into a single function, improving maintainability and making it easier to add new patches. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Renames DurationOfStartCall to InitialStartCallDelay in TypeScript contract tests to match the renamed runtime constant. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Collaborator
|
SDK PR opentensor/bittensor#3234 is covering tests issues from this PR. |
basfroman
approved these changes
Dec 29, 2025
Collaborator
basfroman
left a comment
basfroman
left a comment
There was a problem hiding this comment.
LGTM from SDK perspective
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
The prompt was:
This commit converts the hardcoded
DurationOfStartCallconstant (50400blocks, or ~7 days) into a runtime-configurable hyperparameter called
StartCallDelaythat can be modified via sudo extrinsic.Changes:
StartCallDelaystorage value withDefaultStartCallDelaytype_valueDurationOfStartCallconfig constant toInitialStartCallDelayStartCallDelaySetevent for hyperparameter updatesget_start_call_delay()andset_start_call_delay()functionssudo_set_start_call_delay()extrinsic in admin-utils (call_index 84)DurationOfStartCalltoInitialStartCallDelayStartCallDelay::<T>::get()The delay can now be modified at runtime via the
sudo_set_start_call_delay()extrinsic without requiring a runtime upgrade, providing more flexibility
for network governance.
Users can read the current value through:
state_getStorageRPC callget_start_call_delay()getter function for internal use