# agent durable object test wrote to the production namespace

## TL;DR

The test used the production DO namespace, writing test objects into prod. Isolate by environment: tests get their own namespace (or a test prefix), enforced by config, never by convention. A test that can reach prod will eventually write to prod.

```text
agent durable object test wrote to the production namespace
```

## Steps

1. Assess the pollution: which test objects landed in prod.
   Expected: The extent is known.

2. Delete the test objects from the production namespace carefully.
   Expected: Prod is clean.

3. Give tests their own namespace via environment config.
   Expected: The isolation is structural.

4. Make the test config unable to address prod (no prod binding in test env).
   Expected: The mistake is impossible.

5. Audit other tests for the same prod-reachability.
   Expected: The class of bug is eliminated.

## When to use

- test data appears in the production namespace
- tests share config with prod
- the agent runs DO tests

## When not to use

- the namespace is intentionally shared (then it is not a test)
- the writes were to a staging namespace (verify which)
- the test is a prod smoke test (then prod writes are the point; scope them)

## Tool compatibility

- workerd
- Durable Objects

## Variant phrasings

- "durable object test production namespace"
- "test wrote to prod DO"
- "DO namespace isolation test"

## Why it happens

Namespaces are the DO isolation boundary, and tests that bind the prod namespace inherit prod's identity. 'Be careful' is not isolation; separate bindings per environment is. The test did exactly what its config allowed, which is why config (not care) is the fix.

## Edge cases

- the cleanup must not delete real objects; identify test writes precisely
- staging namespaces need the same protection from dev tests
- the binding allowlist per environment is the enforcement point

## Provenance

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