[SimonWoolf]

Registers 90011, raised by SDKs when Channels#release() is called on a realtime channel that isn't in the initialized, detached or failed state. This is spec RTS4e, added in specification 6.3.0 (ably/specification#557).

The SDK PRs that throw this code are against each SDK's next-major branch. ably-js's typed ErrorCode union means ably/ably-pubsub-js#2323 needs its submodule pin bumped once this merges.

🤖 Generated with Claude Code

[sacOO7]

Could this get a review? The next-major branches of ably-pubsub-js, ably-pubsub-java, ably-pubsub-dotnet, ably-go and ably-pubsub-python already raise 90011 from release() (RTS4e, ably/specification#557), so it would be good to have it registered before those releases.

One small follow-up while this is open. errors/codes/90001.md still lists releasing as a cause (L10, L14). That now only matches ably-js 2.21 and earlier. Since 2.22.0, ably-js detaches implicitly instead of throwing (and 2.30.0 logs the RTS4b deprecation warning). SDKs that implement RTS4e raise 90011 instead. Maybe one sentence there, e.g. "ably-js 2.21 and earlier report releasing a channel that isn't detached as 90001; SDKs that implement RTS4e report it as 90011."

Checked against main @ bb51cc9.

[SimonWoolf]

Could this get a review?

@sacOO7 as the PR author I am the one person who cannot review this. But you could 🙂

Maybe one sentence there, e.g. "ably-js 2.21 and earlier report releasing a channel that isn't detached as 90001; SDKs that implement RTS4e report it as 90011."

I've added a short parenthetical to the 90001. But not with that wording: the target audience for these error pages is users, not SDK developers. Talking about "SDKs that implement RTS4e" is gibberish to end-users, the feature spec is not user-facing documentation.