The generated output of @cloudflare/workers-types matches the snapshot in types/generated-snapshot 🎉

Now I have a thorough understanding of the change. Let me analyze the correctness:

What the PR does: When an actor is constructed with a class name that doesn't exist in the worker's exported classes, the exception is now tagged with EXCEPTION_IS_USER_ERROR. This means that when an alarm fires for such an actor, isAlarmFailureUserError() will return true (via the hasUserErrorDetail check at line 473), causing the alarm retry to count against the user's retry limit rather than retrying indefinitely as an internal error.

Analysis:

1. The change is correct in intent and implementation. A missing actor class is indeed a permanent, irrecoverable user error — the class was renamed/removed but alarms persist. Tagging it as a user error is the right thing to do so retries are bounded.

2. The pattern matches existing usage. Other sites (actor-cache.c++:266, actor-state.c++:1136, global-scope.c++:536,677) use the same e.setDetail(jsg::EXCEPTION_IS_USER_ERROR, kj::heapArray<kj::byte>(0)) idiom.

3. The comment is accurate. The detail IS lost over Cap'n Proto RPC (exception details aren't serialized in the RPC protocol). The comment about the alarm-manager pattern-matching the description string refers to external alarm management code that pattern-matches broken.ignored.

4. No backward compatibility concern. This changes retry behavior for a specific error case (alarm retries now count against limits), but this is an operational improvement, not a user-visible API behavior change. Alarms for deleted actor classes were previously retrying indefinitely as internal errors — that's a bug, not a feature to preserve.

5. No test is added. The existing server test at server-test.c++:1892 covers the "no such actor class" error path for regular requests, but there's no test for the alarm path specifically. However, testing this would require significant alarm scheduling infrastructure, and the change itself is small and straightforward.

The code is clean, follows existing patterns, and the comments are clear and accurate. I don't see any actionable issues.

LGTM

github run