I suggest it be used as such in these scenarios.
:do {<command>} timeout=10s on-timeout={<command>};
:on-timeout timeout=10s in={<command>} do={<command>};
:foreach <index-value> in=<array> do={(<condition>)} \
[timeout=<num> on-timeout={<command>}] \
[on-error={<command>}];
:for <index-value> from=<num> to=<num> do={(<condition>)} \
[timeout=<num> on-timeout={<command>}}] \
[on-error={<command>}];
Justification for Implementing timeout and on-timeout Statements
The addition of a timeout and on-timeout statement to the RouterOS Scripting Language is not merely a feature enhancement, but an engineering necessity to ensure the reliability and efficiency of automation in real-world network environments.
1. Addressing Indefinite Script Blocking
The Current Problem: RouterOS commands often rely on I/O operations and network interactions (e.g., fetch, ping, dns resolve, device access commands). These operations are inherently unreliable in their completion time. If the remote endpoint is unresponsive or if severe network latency occurs, the current scripting engine indefinitely blocks execution, waiting for a result that may never arrive.
I know that there is an argument called "duration" in some paths/commands.
The Proposed Solution: The timeout statement allows the programmer to set a clear maximum execution duration. If the command exceeds this limit, the script is immediately freed to execute a defined fallback plan via the on-timeout block. This prevents indefinite stalling and ensures that critical operations can continue.
2. Enabling Robust Performance Failure Handling
The Current Limitation: The current language structures struggle to differentiate between an "execution error" (handled by on-error) and a "non-response or performance failure."
- Example: A fetch command might technically execute without an error but take 60 seconds due to server slowness, causing a scheduler bottleneck. This is not an error that triggers on-error, but it is a performance failure that compromises system stability.
The Proposed Solution: The on-timeout block provides a dedicated mechanism to handle these performance failures, allowing users to:
-
Log a specific warning or alert.
-
Gracefully retry the operation later.
-
Execute an immediate alternative path (e.g., use a cached value).
3. Supporting Loop Efficiency and Reliability
Applying the timeout mechanism to loop structures (for, foreach) offers significant benefits:
-
Efficiency: If a loop iterates through checks (e.g., verifying 100 devices), an unresponsive single device will no longer halt the entire operation. The on-timeout allows the script to skip the unresponsive element and immediately proceed to the next iteration.
-
Scheduling: It ensures that multi-tasking scripts do not consume more time than allotted, thereby protecting the integrity of the Scheduler's timing.
In summary: This feature is essential for meeting modern programming standards and providing engineers with powerful tools to build more stable, more efficient, and more reliable network automation on the RouterOS platform.