# workerd error: r2 lifecycle rule conflict

## TL;DR

Two lifecycle rules match the same objects with contradictory actions (one expires, one transitions). Rules are evaluated in order; make them disjoint or order them deliberately. Conflicting rules are a config bug, not a platform bug.

```text
workerd error: r2 lifecycle rule conflict
```

## Steps

1. List the lifecycle rules and their filters.
   Expected: The overlap is visible.

2. Identify the conflicting pair: same prefix, different actions.
   Expected: The conflict is named.

3. Make the filters disjoint or order them so the intended rule wins.
   Expected: The conflict resolves.

4. Apply and verify with a test object.
   Expected: The behavior is correct.

5. Document the rule set with its intent; review on change.
   Expected: The config stays coherent.

## When to use

- lifecycle rules conflict
- objects get unexpected actions
- rules were added independently

## When not to use

- a single rule misbehaves (that is the rule's logic)
- the error is on rule syntax (different problem)
- no lifecycle rules exist (check the bucket config)

## Tool compatibility

- workerd
- R2 lifecycle

## Variant phrasings

- "r2 lifecycle rule conflict"
- "lifecycle rules contradict r2"
- "r2 rule overlap"

## Why it happens

Lifecycle rules are a list, and overlapping filters with different actions create ambiguity the platform resolves by order, not by intent. Two teams adding rules independently is how conflicts are born. The fix is making the filters disjoint, which is a design task, not a syntax task.

## Edge cases

- rule evaluation order is the tiebreaker; know it
- test with a canary prefix before applying broadly
- version the bucket config so rule changes are reviewable

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_X5Cxjdk1A9nSwM5sTZ0qWg