Skip to main content

Avoid duplicate work with dry runs and recovery IDs

Estimate cost, make retries idempotent, and resume the original work.

Written by Josh Whitfield

Avoid duplicate work with dry runs and recovery IDs

Signaliz exposes three controls for reliable automation: dry runs, idempotency keys, and durable recovery IDs.

Preview with a dry run

Set dry_run: true in REST, dryRun: true in the SDK, or --dry-run in the CLI. A dry run returns a conservative credit ceiling and duplicate-suppression counts without provider calls, jobs, writes, or spend.

Choose an idempotency key

Create one stable key for one workspace and one logical submission. Store it before the network call. If the response is lost or ambiguous, retry with the same key so Signaliz can recover the original run or job.

Use a new key only when the error explicitly instructs retry_strategy=new_idempotency_key and confirms both credits_used=0 and credits_charged=0.

Resume, do not repeat

  • run_id or product-specific run IDs resume a single long-running or completed run.

  • job_id retrieves a durable batch larger than 25 rows.

  • Signals First uses signal_search_run_id to resume the same discovery snapshot.

Recovery identifiers are workspace-bound. A key or job created in one workspace should not be expected to resolve in another.

Handoff checklist

When an agent, worker, or teammate yields the task, save the product, workspace, idempotency key, run/job ID, status, input count, credits, and next poll instruction. A repeated natural-language prompt is not sufficient recovery state.

Did this answer your question?