Observed Behavior
When an execution host running RapiseLauncher goes offline or becomes inactive, scheduled Test Sets may miss their scheduled execution times. When the host comes back online, you may observe the following behavior:
All pending/missed executions are launched repeatedly.
A new execution of the same Test Set is triggered on every polling cycle (or when clicking "Force Poll").
This loop continues indefinitely or for an extended period.
This issue specifically occurs with recurring schedules (e.g., hourly, daily) rather than "One Time" executions.
Root Cause
This is the expected behavior based on how SpiraTest calculates recurring schedules and how RapiseLauncher handles overdue tests. The "execution loop" is caused by the system attempting to "catch up" on all missed runs sequentially.
Here is the underlying sequence of events:
When RapiseLauncher comes back online, it polls SpiraTest and finds a recurring Test Set with a Planned Date in the past.
Because the "Automatically run tests that are overdue" setting is enabled in RapiseLauncher, it executes the missed test immediately.
Upon completion, SpiraTest calculates the next execution time by adding the recurrence interval (e.g., 1 hour, 1 day) to the original Planned Date—not the current clock time.
If the newly calculated Planned Date is still in the past (which happens if the host was offline for multiple recurrence cycles), RapiseLauncher sees it as overdue again on the next poll cycle and executes it immediately.
This cycle loops until the scheduled Planned Date finally catches up to the present/future.
Resolution
Currently, SpiraTest does not silently discard missed recurrences to snap the schedule to the current time. To break the execution loop or prevent it from happening, you can use one of the two methods below:
Method 1: Manually Fast-Forward the Planned Date (To break an active loop)
To stop the immediate repeated executions and reset your schedule, you must manually push the schedule to a future date.
Log in to SpiraTest.
Navigate to Testing > Test Sets.
Locate and click on the affected recurring Test Set.
In the schedule settings, change the Planned Date to your next desired execution time in the future.
Click Save.
RapiseLauncher will now wait until that future date to resume execution, and subsequent recurrences will calculate correctly from that point forward.
Method 2: Disable Overdue Executions in RapiseLauncher (To prevent future loops)
If you prefer that an offline host simply ignores past-due tests when it boots back up, you can change the RapiseLauncher configuration.
Open the RapiseLauncher application on your execution host.
Click on the Client Setup tab and navigate to the Server Polling configuration section.
Uncheck the option for "Automatically run tests that are overdue".
Click Save.
Note: If you disable this setting, any Test Set that misses its scheduled time will simply sit in SpiraTest in an Overdue state and will not be executed. You will still need to log into SpiraTest and manually update the Planned Date to a future time to resume the recurring schedule.
Advanced Orchestration: Using the TestRunner Module (Rapise 8.4+)
As of Rapise 8.4, an excellent alternative to relying purely on SpiraTest's individual, time-based recurrence schedules is the TestRunner public module.
Instead of scheduling every Test Set individually, you can use the TestRunner module to build a centralized Orchestration Framework. This master script acts as an intelligent controller, programmatically triggering other test sets only when the host is actively executing it, preventing offline "catch-up" loops.
Benefits of TestRunner Orchestration:
Run Multiple Test Sets: Trigger the execution of dozens of test sets in a specific order via the Spira.RunTestSet action from a single "master" test case.
Automatically Rerun Failures: Use the TestRunner.DoRerunFailedAndNotRun action to gracefully detect and rerun tests that failed or were blocked (e.g., due to temporary network drops or host disconnects).
Historical Analysis & Reports: Automatically compile execution results into a comprehensive HTML or PDF report (TestRunner.DoDailySummaryReport), and optionally use AI (AITester module) for root cause analysis on failed runs.
How to implement:
Open your test framework in Rapise.
Right-click Modules / Pages in the Object Tree, select Import Public Module, and install TestRunner (and AITester, if utilizing AI features).
Create a master orchestration script in RVL.
Add Spira.RunTestSet actions to queue your desired Test Sets on the execution host.
Schedule only this master orchestration script in SpiraTest. When RapiseLauncher picks it up, the module will handle the structured execution of your framework without falling into recurrence loops.