Core Configuration

The primary building block of a Rumour test suite is the Request Node, defined in a .toml file. Each node represents a single HTTP transaction and contains the target URL, method, headers, query parameters, assertions, and variables.

This guide covers the root-level configuration and the core [request] table.

1. Root-Level Directives

These settings are configured at the absolute root of the .toml file and control the execution lifecycle, order, and error handling of the node itself.

# Example of root-level directives
skip = false
retries = 3
ordered = true

[request]
method = "GET"
url = "{{base_url}}/health"

1. The runner must wait for the previous attempt of a request to fail before it can determine if another attempt is required.
2. If only one request/file is run, parallel mode offers no speedup over sequential mode.

Directive	Type	Default	Description
skip	Boolean	false	If set to true, the runner skips this request node entirely.
retries	Integer	0	Number of times to retry the request if its assertions fail.
ordered	Boolean	false	Forces strict chronological execution sequencing relative to other nodes.
pre_request	String (Path)	None	Path to a pre-request script (e.g. Python or shell) executed before the request runs.
post_request	String (Path)	None	Path to a post-request script executed after the response is received.

The skip Directive

If you set skip = true, Rumour will skip the request node entirely when executing the test suite or file.

Example:

skip = true
retries = 3
ordered = true

[request]
method = "GET"
url = "{{base_url}}/get"

Even if you execute only this single file directly, Rumour still respects skip = true and skips its execution:

~/workspace/testing/core_configuration/root_level_directives main* ❯ rumour run requests/skip_example.toml 
    ✓ requests/skip_example.toml → PASS (0 Pass, 0 Fail, 1 Skip)                                                                      
╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT                                                  │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests:      1                                                   │
│ Successful:          0                                                   │
│ Failed:              0                                                   │
│ Skipped:             1                                                   │
│ Success Rate:        0.0%                                                │
│ Total Time:          0ms                                                 │
╰──────────────────────────────────────────────────────────────────────────╯

Actionable Recommendations:
  → Use -v -t to see detailed latency and response diagnostics.
  → Run with --json to export this report for your CI/CD pipeline.
  → Hint: Check your variable dependencies if nodes are unexpectedly skipped.

The retries Directive

When a request node fails (assertions fail or a transport/network error occurs), Rumour retries the request using an exponential backoff strategy.

• Exponential Backoff Formula: Delay = 500ms * 2^(attempt - 1)
• Max Delay Cap: The delay is capped at a maximum of 512,000ms (~8.5 minutes) per attempt.
• Delay Progression:
  • Attempt 1: Waits 500ms before running.
  • Attempt 2: Waits 1,000ms before running.
  • Attempt 3: Waits 2,000ms before running.
  • Attempt 4: Waits 4,000ms before running.
  • Attempt 5: Waits 8,000ms before running.
  • Attempt 10 and beyond: Capped at 512,000ms per attempt.

Keep Retries Low

If a request fails permanently (e.g. hitting a static 404 Not Found endpoint), setting retries = 300 will cause the test suite to hang and take over 38 hours to complete the entire run. It is highly recommended to keep retries low (e.g., 3 to 5 attempts).

note

For more details on retries and backoff limits, see the Retry Behavior Guide.

Sequential Retries in Parallel Mode

Even when running suite execution in parallel mode (using the -p or --parallel flag), the retry attempts for any single node are always sequential.

The ordered Directive

When running a folder or suite of request nodes, Rumour's scheduler runs independent request nodes concurrently in parallel mode by default.

By setting ordered = true or ordered = false, you control whether the request node must be executed sequentially relative to other nodes in the workspace/suite.

• ordered = true: Forces the execution engine to wait for preceding requests in the collection or folder sequence to complete before initiating this request. It establishes a virtual dependency edge in the directed acyclic graph (DAG).
• ordered = false (Default): Allows Rumour's scheduler to execute the node concurrently with other independent requests in parallel mode (using -p or --parallel), ignoring the default chronological collection ordering.

Example:

skip = false
retries = 3
ordered = true

[request]
method = "GET"
url = "{{base_url}}/get"

When you run the request, Rumour compiles the configuration and outputs the execution trace and report:

• Request Line: Prints the request method and resolving URL: GET https://httpbin.org/get.
• Execution Result: Denotes node completion, execution time (1186ms), and overall status.
• Execution Report Table: Displays total requests executed, success counts, failure counts, skipped counts, success rate, and total run duration.

If you keep ordered = false and execute the collection in parallel mode, Rumour runs this request concurrently with other independent nodes in the folder, rather than sequentially waiting for previous requests.

The pre_request and post_request Directives

Rumour allows you to attach external scripts (such as Python, Node.js, or shell scripts) to execute before the request runs or after the response is received.

• pre_request: Path to a script that executes before the request is initiated. Useful for generating dynamic request headers, cryptographic signature hashes, or setting up test database entries.
• post_request: Path to a script that executes after the response has been received. Useful for custom reporting, updating external files, or managing state cleanup.

To learn more about implementing lifecycle hooks, see the:

• Pre-Request Hooks Guide
• Post-Request Hooks Guide

Next Steps

Now that you understand the root-level settings and directives:

• Configure custom headers in the HTTP Headers Guide.
• Add query parameters in the Query Parameters Guide.
• Specify request payloads in the Request Body Guide.