# workerd error: workflows instance already running

## TL;DR

A workflow instance with that id is already running; ids are unique. Either wait for it, use a new id, or design the workflow to be idempotent so re-triggers are safe. Duplicate starts are usually a retry or a double trigger.

```text
workerd error: workflows instance already running
```

## Steps

1. Check the running instances for the id.
   Expected: The duplicate is confirmed.

2. Decide: if the running one is healthy, let it finish; if it is stuck, terminate it.
   Expected: The state is resolved.

3. Fix the trigger: dedupe the event source so it does not fire twice.
   Expected: Double triggers stop.

4. Make the workflow idempotent: re-running with the same id should be safe.
   Expected: Retries are harmless.

5. Use unique ids per logical run (event id, timestamp) instead of fixed names.
   Expected: Collisions stop.

## When to use

- starting a workflow instance that is already running
- retries or double triggers
- fixed instance ids are used

## When not to use

- no instance is running (check the id carefully)
- the error is on a different resource (read it)
- instances are meant to be singletons (then the error is correct behavior)

## Tool compatibility

- workerd
- Workflows

## Variant phrasings

- "workflows instance already running"
- "duplicate workflow instance"
- "workflow id collision"

## Why it happens

Workflow ids are the dedup key: starting the same id twice is either a retry or a bug, and the system refuses the second. Fixed ids (like 'daily-sync') collide on every re-trigger. Unique ids per run plus idempotent steps make the whole thing robust.

## Edge cases

- terminating a stuck instance needs care; it may hold resources
- the trigger dedup belongs at the event source, not just in the workflow
- idempotency must cover external side effects, not just internal state

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QkEScGxR3JSOezoGndUN-w