> ## Documentation Index > Fetch the complete documentation index at: https://docs.runflow.ai/llms.txt > Use this file to discover all available pages before exploring further. # Testing and operations > Validate safely, understand run states, handle retries, and diagnose failures ## A practical release process 1. Create a draft or work on a separate inactive automation. Keep stable section IDs and step keys when updating an existing definition. 2. Validate configuration, referenced resources, input mappings, and credentials. Validation does not prove a remote API will accept a request. 3. Test one section with representative data: normal input, missing fields, empty results, duplicate events, external failure, and expired context. 4. Inspect the complete step report and the `matched` result. Section tests can execute the selected section even when its entry conditions do not match; they do not prove live routing by themselves. 5. Review the active trigger bindings and every destination. Editing an active definition affects subsequent requests. 6. Activate for a controlled real event only when real side effects are intended. Confirm external receipts and stored context, then observe live runs. ## What test mode executes | Block | Test-mode behavior | | - | - | | Transform, If, For each, Parallel, Return | Execute their logic | | KV read, agent-memory read, configuration selection | Read configured data | | KV write, agent-memory write | Simulated; subsequent reads do not see a real write from this test | | Connector | Simulated, including connector reads; returns a simulated result, not the real resource schema | | HTTP GET | Real request | | HTTP POST / PUT / PATCH / DELETE | Simulated | | Send message | Simulated; does not establish a real provider message ID | | LLM | Real model call; may incur cost | | Knowledge search | Real search | | Agent | Simulated submission | > [!WARNING] > > Test mode is not an offline emulator and does not supply realistic outputs for every integration. A downstream step that expects real connector data or a provider message ID can fail against the simulated result. Use representative fixtures in isolated contract tests, or an explicitly authorized controlled integration test. Do not enable a live flow merely to get around a simulation limitation. ## Run states and step results Persisted runs use `QUEUED`, `RUNNING`, `SUCCEEDED`, and `FAILED`. Step reports use `succeeded`, `failed`, and `skipped`, with input/output records and duration when available. * `onError: "stop"`: fail the section when the step fails, rather than executing later business steps. * `onError: "continue"`: record the error and continue. This is useful for optional diagnostics, but a successful run may then contain a failed callback. * A false step condition records a skip. * Return ends the section successfully, including an intentional no-op. Always inspect steps when checking business success. `SUCCEEDED` alone does not prove a message was delivered, a callback succeeded, or a record was eligible for sending. Audit payloads may be truncated; the stored preview is not necessarily the full original request or output. ## Idempotency, retries, and uncertainty Use a stable `X-Idempotency-Key` for repeated delivery of the same webhook operation. Direct webhooks can otherwise derive their deduplication identity from the body. Channel statuses deduplicate by automation, provider message ID, and status. Deduplication is bounded in time and is not a permanent business rule. The worker retries errors classified as retryable and can checkpoint completed steps before resuming. Rate-limited sends can be deferred. Not every HTTP or connector failure is automatically retryable. Integrations receive stable per-step idempotency headers where supported; the receiving service must honor them. **Exactly-once external effects are not guaranteed.** A worker can fail after a remote service accepted a request but before local persistence completed. A retry or a manual replay must not assume that no effect occurred. Confirm receipts, message IDs, or the remote system's idempotency record before repeating an uncertain operation. There is no automatic rollback across multiple services. Use a business idempotency key that reflects the intended operation. For example, a recipient and a campaign ID may be insufficient when the same campaign has multiple distinct sends. Document the delivery identifier explicitly, and test repeated delivery separately from a new authorized operation. ## Execution limits These are current validation/runtime limits, not throughput guarantees: | Item | Limit | | - | - | | Sections per automation | 10 | | Configured steps per section | 40, including nested steps | | Control-flow nesting | Up to 3 levels | | Section entry conditions | Up to 10 | | For each input | Up to 100 items; sequential execution | | Parallel group | 1–8 ordinary child actions; concurrency 1–4; no nested control blocks | | Runtime step budget | 1,000 visited steps per section attempt, including iterations | | Transform source | 20 KB | | Transform runtime defaults | 500 ms, 256 KB output | | Inbound payload | 1 MB | | Agent-memory write | 64 KB serialized record | | LLM prompt / instructions | 20,000 characters each | | LLM output token setting | Up to 8,000 | | Knowledge results | Up to 50 | Do not submit a large customer list as one loop and expect unlimited fan-out. Split work into independently identifiable events and respect admission and provider limits. A schedule or automation is not a replacement for capacity planning. ## Diagnose a run | Symptom | Check | | - | - | | Automation menu or MCP tools missing | Workspace feature availability and your access | | No run created | Active status, entry conditions, trigger destination, authentication, and admission response | | Queued for longer than expected | Queue depth, worker health, dependency latency, and configured rate limits | | Validation failure | Input shape, required identifiers, selector paths, and referenced resources | | Successful run, missing callback | Failed or skipped steps with `onError: continue`; missing correlation | | Message accepted but not delivered | Provider status/error event and the exact provider message ID | | Context unavailable when the user replies | Namespace, agent/environment, message ID, key contract, and expiry | | Rule differs from the agent | Published definition/version and shared business-contract tests | | Error saving a result | Persisted run error; do not infer that external actions did not happen | The Portal provides run and step inspection. MCP exposes the same information through `list_automation_runs` and `get_automation_run`. Platform monitoring can expose queue depth, terminal outcomes, step failures, retries, execution duration, worker health, and scaling. Queue job completion and business run success are different signals. ## Pause, revert, and retain evidence Pause to stop new admissions, not to cancel accepted executions. To revert definition changes, restore a reviewed prior definition and validate it. To restore a trigger's agent destination, remove the relevant automation binding and separately inspect already queued work. Avoid enabling both paths for the same event. History retention is deployment-configurable (default 14 days). Export the evidence you need before retention removes it. Delete removes the automation and its history; it is not a pause operation. Keep credentials and token-bearing webhook URLs out of exported examples and source control. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.