agent durable object test wrote to the production namespace

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.

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