set_retry_named
Call v151 → current #7Configure retry behavior for a named scheduled task.
View calls on chainCall Workflow
Click items to navigate. Pan and zoom to explore.
The Big Picture
Ergonomic retry configuration for named tasks using task name instead of (block, index).
Use Cases
- Add retry logic to named operations
- Configure resilience by name
From Chain Metadata
Set a retry configuration for a named task so that, in case its scheduled run fails, it will be retried after `period` blocks, for a total amount of `retries` retries or until it succeeds. Tasks which need to be scheduled for a retry are still subject to weight metering and agenda space, same as a regular task. If a periodic task fails, it will be scheduled normally while the task is retrying. Tasks scheduled as a result of a retry for a periodic task are unnamed, non-periodic clones of the original task. Their retry configuration will be derived from the original task's configuration, but will have a lower value for `remaining` than the original `total_retries`.
Input Parameters
Permissions
Permission data inferred from metadata. May be incomplete.
Requirements
- Named task exists in Lookup
- Period at least 1 block
Effects
Code Examples
import { ApiPromise, WsProvider } from "@polkadot/api";
import { stringCamelCase } from "@polkadot/util";
const provider = new WsProvider("wss://entrypoint-finney.opentensor.ai:443");
const api = await ApiPromise.create({ provider });
// Build set_retry_named call
const id = 0;
const retries = 0;
const period = 0;
const call = api.tx[stringCamelCase("Scheduler")][stringCamelCase("set_retry_named")](
id,
retries,
period
);Runtime Info
- Pallet Index
- 15
- Call Index
- 7
- First Version
- v151
- Current Version
- v393