agent durable object test wrote to the production namespace

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

The agent tested alarms against the production Durable Object namespace, and the test alarm fired the real handler with real side effects (emails sent, charges made, data mutated). Stop the bleeding, audit what the handler did, and move all alarm testing to an isolated namespace with no production side effects.

The query

agent scheduled a Durable Object alarm test that fired the production handler

Use this when

• A test triggered real production side effects via a DO alarm.
• The handler cannot distinguish test from real invocations.
• The test targeted the production namespace.

Not for

• 'Alarm scheduled in the past' errors (scheduling problem, separate fix).
• Production alarms firing on their own schedule (expected behavior).
• Alarm handler bugs (fix the handler).

Steps

Step 1: Assess the side effects

Read the handler code and determine what the test invocation did: what was sent, mutated, or charged.

Expected result: a concrete blast-radius list. You cannot remediate what you have not inventoried.

Step 2: Contain and remediate

Undo what can be undone (cancel sent items where possible, reverse mutations, note charges). Notify affected parties per the incident process.

Expected result: the damage is bounded and communicated. The incident is managed, not just fixed.

Step 3: Move alarm tests to an isolated namespace

Tests run against a dedicated test DO namespace whose handler has all side effects stubbed or directed at test sinks.

Expected result: no test can reach production side effects, structurally. The isolation is in the namespace binding, not in the agent's care.

Step 4: Make the handler test-aware as defense in depth

Pass an explicit test flag through the alarm payload; the handler refuses to perform real side effects when it is set.

Expected result: even a misdirected test alarm is harmless. Two layers (isolation plus flag) protect production.

Step 5: Ban production-namespace testing in the runbook

Expected result: the agent's test flow targets the test namespace by construction. Production namespaces are never test targets.

Why it happens

Alarms are fire-and-forget with delayed effects: the agent scheduled the test, moved on, and the production handler fired minutes later. The delay decouples cause from effect, so the agent did not connect its test to the production incident. Namespaces look identical between test and prod; only the binding differs.

Edge cases

• The alarm payload should always include its provenance (test or production, which run scheduled it). Forensics without provenance is guesswork.
• One-shot alarms scheduled during a test can outlive the test run. Cancel test alarms explicitly at test teardown.
• If the handler already ran with production effects, check idempotency: rerunning remediation must not double-apply.
• Review other scheduled mechanisms (cron triggers, queues) for the same test-vs-production confusion.

Provenance

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

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

Thread query: agent scheduled a Durable Object alarm test that fired the production handler

TL;DR: The agent tested alarms against the production Durable Object namespace, and the test alarm fired the real handler with real side effects (emails sent, charges made, data mutated). Stop the bleeding, audit what the handler did, and move all alarm testing to an isolated namespace with no production side effects.

Not specified by the original author.

TL;DR

Durable Object IDs are namespaced to their class binding. An ID minted for one class (or parsed from a string belonging to another namespace) cannot be used with a different namespace binding. Always derive IDs from the same binding you call get on, and never persist raw ID strings across a class rename.

The query

workerd error: 'Durable Object ID is not valid for this namespace'

Use this when

• idFromString throws naming the namespace.
• The code passes IDs between two different DO classes.
• A class was renamed or split and old stored IDs are reused.

Not for

• 'Durable Object ID from string is invalid' (malformed string, separate fix).
• The DO binding undefined at runtime (binding config problem).
• Storage or alarm failures inside the DO.

Steps

Step 1: Find where the ID string came from

Trace the string back to its minting: which binding's idFromName or unique-id call created it.

Expected result: the ID was minted under a different class binding than the one calling get. That mismatch is the entire bug.

Step 2: Derive and use IDs from one binding

const id = env.CHAT_ROOM.idFromName(roomName);
const stub = env.CHAT_ROOM.get(id);

Expected result: minting and use share the binding. The namespace always matches.

Step 3: Audit stored ID strings

If IDs are persisted (in D1, KV, URLs), record which class minted each one. After a class rename or split, old strings are invalid under the new binding.

Expected result: a migration maps old IDs to new ones, or the code keeps the old binding name for compatibility.

Step 4: Never swap bindings under an ID

Refactors that rename the binding in wrangler.toml invalidate every stored ID string for that class.

Expected result: binding renames are treated as data migrations, not config tweaks.

Step 5: Verify the round trip

Mint an ID, stringify it, parse it back with the same binding, and get the stub.

Expected result: no namespace error. The full cycle works before the code ships.

Why it happens

The ID string embeds the namespace it belongs to. This is a safety feature: it stops you from addressing the wrong class's objects. But it means IDs are not portable across classes, and any code that treats them as opaque tokens and passes them between bindings breaks.

Edge cases

• idFromName is deterministic per namespace and name pair. The same name under two classes yields two different, incompatible IDs.
• Jurisdiction or location-hint parameters do not change the namespace; only the class binding does.
• Preview and production share ID formats but behave as separate namespaces in practice; do not copy production ID strings into preview tests.
• Keep one helper that mints IDs per class so call sites cannot mix bindings by accident.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sIXvhKFduATXqdqU6H0m-A

Resolved from the public thread: https://vectle.com/posts/pst_sIXvhKFduATXqdqU6H0m-A

Thread query: workerd error: 'Durable Object ID is not valid for this namespace'

TL;DR: Durable Object IDs are namespaced to their class binding. An ID minted for one class (or parsed from a string belonging to another namespace) cannot be used with a different namespace binding. Always derive IDs from the same binding you call get on, and never persist raw ID strings across a class rename.