Skip to main content

Interactive Recovery Flows

Welcome to the Interactive Recovery Flows documentation!

When testing live environments, intermittent network failures, out-of-sync state, or missing resources are inevitable. Instead of just reporting a failure and forcing you to manually fix the database and re-run the entire test suite, Rumour provides a robust Self-Healing Engine designed to automatically detect and correct environmental issues on the fly.

1. Automated Retries (Default Behavior)​

By default, any request that fails its [assert] block or encounters a transient network error (like a timeout or TCP disconnect) is automatically retried.

Rumour uses an exponential backoff algorithm:

  • Attempt 1 fails.
  • Wait 500ms.
  • Attempt 2 fails.
  • Wait 1000ms.
  • Attempt 3 fails. (Marks node as completely failed).

During a run, you will see this real-time output:

  ✗ FAILED: test_timeout.toml (3001ms) - Network Error: timeout
  ↻ RETRYING: test_timeout.toml (Attempt 1/2) [Wait 500ms]
  ✗ FAILED: test_timeout.toml (3000ms) - Network Error: timeout
  ↻ RETRYING: test_timeout.toml (Attempt 2/2) [Wait 1000ms]

(You can disable this behavior using retries = 0 inside your .toml file).

2. The Self-Healing Engine (-H / --heal)​

If standard retries fail, Rumour can attempt to intelligently fix the reason for the failure. By passing the -H or --heal flag, you activate the healing engine.

Detecting Missing Resources (404)​

If an endpoint returns a 404 Not Found (often because a prerequisite ID was deleted from the database between test runs), Rumour's healing engine detects this specific symptom.

rumour run ./failing_node.toml -v -H

Healing Trace Output​

  GET http://localhost:4000/api/v2/non_existent_endpoint
  URL: http://localhost:4000/api/v2/non_existent_endpoint
  ✗ FAILED: /home/bugsfounder/workspace/testing/advanced_examples/failing_node.toml (11ms) - HTTP Status: Expected status 200, got 404
    ✗ ./failing_node.toml → FAIL (0 Pass, 1 Fail, 0 Skip)                                                                            
╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT                                                  │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests:      1                                                   │
│ Successful:          0                                                   │
│ Failed:              1                                                   │
│ Skipped:             0                                                   │
│ Success Rate:        0.0%                                                │
│ Total Time:          1536ms                                              │
╰──────────────────────────────────────────────────────────────────────────╯

🔧 Self-Healing Recovery Log:
  → Node: /home/bugsfounder/workspace/testing/advanced_examples/failing_node.toml
    Action:  Resource Missing (404)
    Outcome: Enable 'Hard Healing' to automatically reconstruct missing resources.

✗ Failed Requests:
  - /home/bugsfounder/workspace/testing/advanced_examples/failing_node.toml: [404]
    Reason: HTTP Status: Expected status 200, got 404

Hard Healing (-X / --hard-heal)​

As hinted by the recovery log, if Rumour detects a 404, and you have enabled --hard-heal, Rumour will pause the current execution, traverse backwards up the dependency graph, find the specific request that creates the missing resource (e.g., POST /users), re-execute it, extract the new ID, and then seamlessly resume your original request without failing the test suite.

3. Interactive Mode (-i / --interactive)​

If an unexpected failure occurs that Rumour cannot automatically heal (e.g., a schema validation fails because the API contract unexpectedly changed), you can run your suite in Interactive Mode.

rumour run ./integration_suite/ -i

When a request fails, instead of halting the suite, Rumour will pause execution and present a terminal prompt:

⚠ Failure in node: ./get_user.toml
  Error: JSON Path: email: Expected 'test@swahira.io', got 'admin@swahira.io'

How would you like to proceed?
  [1] Persona Switch (Try another user identity)
  [2] Resource Reconstruction (Try creating missing dependencies)
  [3] Smart Mutation (Try auto-fixing payload issues)
  [4] Retry (Execute this node again)
  [5] Skip (Mark as failed and continue workflow)
  [6] Abort (Stop entire workflow immediately)

Select an option [1-6]:

This allows you to select a targeted recovery action or manually fix out-of-band issues (like resetting a database record manually) and then select [4] to retry the request or [5] to skip and continue.