Skip to main content

Automated Resource Cleanup

Auto-cleanup automatically runs DELETE-type or cleanup request nodes after a workflow completes, destroying resources that were created during the session. This keeps your test environment clean between runs.

Enabling Auto-Cleanup​

CLI Flag​

rumour run ./requests/ -C
# or
rumour run ./requests/ --auto-cleanup

Collection Config File​

# api.config.toml
[config]
auto_cleanup = true

How Cleanup Nodes Are Discovered​

When the session ends and at least one resource was created, Rumour searches for cleanup nodes in two steps:

Step 1 — Graph-based discovery​

Looks in the current workflow graph for any node whose filename contains delete or cleanup (case-insensitive):

requests/
├── create_post.toml    ← creates resource
├── get_post.toml
└── delete_post.toml    ← auto-cleanup picks this up ✅

Step 2 — Filesystem fallback​

If no cleanup nodes are in the graph, Rumour scans the directories of all passed nodes for any .toml file whose name contains delete or cleanup.

important

Naming is critical. Your deletion request file must contain delete or cleanup in the filename for auto-discovery to work.

Resource Tracking​

Rumour tracks created resources automatically. When a node extracts a variable after a successful POST/PUT, it records it in the session's creation_vars store. Cleanup nodes receive these variables in scope, so {{post_id}} in delete_post.toml resolves to the ID created during the session.

Example​

A POST creates a resource, then -C triggers delete_post.toml automatically at the end.

File Layout​

config_examples/07_auto_cleanup/
├── workspace.env.toml
├── create_post.toml
└── delete_post.toml

workspace.env.toml​

base_url = "http://localhost:4000/api/v2"

create_post.toml​

name = "create_post"

[request]
method = "POST"
url    = "{{base_url}}/posts"

[headers]
Content-Type = "application/json"

[body]
type = "json"
raw  = '{"title":"Temp Post","body":"Will be cleaned up","userId":1}'

[assert]
status = 201

[extract]
post_id = "id"

delete_post.toml​

name = "delete_post"

[request]
method = "DELETE"
url    = "{{base_url}}/posts/{{post_id}}"

[assert]
status = 204

Run​

rumour run ./07_auto_cleanup/ -C -v

Output​

  POST http://localhost:4000/api/v2/posts
  Header: Content-Type: application/json
  URL: http://localhost:4000/api/v2/posts
  Body (json): {"title":"Temp Post","body":"Will be cleaned up","userId":1}
  ✓ SUCCESS: /home/bugsfounder/workspace/testing/config_examples/07_auto_cleanup/create_post.toml (1ms)
  DELETE http://localhost:4000/api/v2/posts/27
  URL: http://localhost:4000/api/v2/posts/27
  ✓ SUCCESS: /home/bugsfounder/workspace/testing/config_examples/07_auto_cleanup/delete_post.toml (0ms)
  🗑 Cleaning up resource: /home/bugsfounder/workspace/testing/config_examples/07_auto_cleanup/delete_post.toml ({"create_post.post_id": "27", "create_post.id": "27", "id": "27", "post_id": "27"})
  DELETE http://localhost:4000/api/v2/posts/27
  URL: http://localhost:4000/api/v2/posts/27
  ✗ FAILED: /home/bugsfounder/workspace/testing/config_examples/07_auto_cleanup/delete_post.toml (0ms) - HTTP Status: Expected status 204, got 404
    ✓ config_examples/07_auto_cleanup → PASS (2 Pass, 0 Fail, 0 Skip)                                                                             
╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT                                                  │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests:      2                                                   │
│ Successful:          2                                                   │
│ Failed:              0                                                   │
│ Skipped:             0                                                   │
│ Success Rate:        100.0%                                              │
│ Total Time:          6ms                                                 │
╰──────────────────────────────────────────────────────────────────────────╯

✓ Successful Requests:
  - /home/bugsfounder/workspace/testing/config_examples/07_auto_cleanup/create_post.toml  [201] [3ms]
  - /home/bugsfounder/workspace/testing/config_examples/07_auto_cleanup/delete_post.toml  [204] [1ms]

Actionable Recommendations:
  → Run with --json to export this report for your CI/CD pipeline.

Understanding the Output​

In the execution logs above:

  1. Normal Workflow Run: Rumour executes create_post.toml (returning 201 and registering the post ID 27 in the creation store) followed by delete_post.toml (deleting post 27 and returning 204).
  2. Auto-Cleanup Phase: Since the -C flag was specified, the Auto-Cleanup engine executes at the end of the workflow. It detects that post 27 was created during the session and automatically queues delete_post.toml to delete it.
  3. Expected 404 Warning: Because the post was already deleted during the normal workflow run, this second deletion request returns 404 Not Found from the server. Because the request expects a 204 status (status = 204 on line 105), the cleanup run outputs a ✗ FAILED warning.
  4. Main Status Unaffected: Notice that the overall suite execution report reports PASS (with Failed: 0). This is because cleanup node failures do not affect the exit code or status of the main test suite.

To prevent the cleanup engine from outputting ✗ FAILED warnings when deleting already-deleted resources, you should configure your cleanup assertions to accept both successful deletion and resource absence (see the caution callout and the flag combinations sections below).

Best Practices​

  • Always name deletion files with delete or cleanup in the filename.
  • Use cleanup in CI/CD pipelines to prevent stale test data from causing failures in subsequent runs.
  • Test cleanup nodes independently before relying on them for automated cleanup.
caution

If the server is unavailable or the resource was already deleted, cleanup node failures are logged but do not affect the main execution report result.

Combining with Other Flags​

Cleanup + Soft Healing (-C -H)​

# Cleanup + soft healing (heal suite execution failures, cleanup runs at end)
rumour run ./crud_tests/ -C -H

Soft healing (-H) applies to requests executed during the main workflow, recovering from transient errors (like token expiration or server timeouts) to ensure the suite successfully finishes.

However, during the cleanup phase itself, healing strategies (both Soft and Hard Healing) are disabled. If a cleanup DELETE request fails (e.g. if a token expires during cleanup or the server is temporarily down), the failure is recorded in the recovery report logs but no healing or retries will be performed.

Cleanup + Parallel (-C -p)​

# Cleanup + parallel (cleanup runs at end regardless)
rumour run ./crud_tests/ -C -p

Cleanup + Resume (-C -r)​

# Cleanup + resume
rumour run ./crud_tests/ -C -r

Cleanup + Hard Healing (-C -X)​

# Cleanup + hard self-healing (reconstruct missing resources, clean up all created instances)
rumour run ./crud_tests/ -C -X

If a resource is missing (404) during workflow execution, Hard Self-Healing reconstructs it by re-running its creator node. Both the original (lost) resource ID and the new (reconstructed) resource ID are registered in the session's tracked creations.

At the end of the session, the Auto-Cleanup engine will execute the cleanup node once for each registered ID. Since the original resource is already absent, the deletion request for it will return a 404 Not Found response. To ensure these expected 404s do not log failure warnings in the CLI output, define the cleanup node's assertions to accept both successful deletion and resource absence:

# delete_post.toml
[assert]
status = [204, 404]