Error codes

Use the error codes provided, which include descriptions, possible causes, and solutions, to troubleshoot issues effectively.

This error occurs when there is an issue within Ably’s system.

This error occurs when there is an issue within Ably’s system.

This error code indicates that the attempted action was successful and no issues occurred; there will be additional info in the message property about the successful action.

This error code is a generic response used when the Ably protocol requires an errorInfo object, even though no actual issue has occurred. The message property may contain additional details about the successful action.

This error occurs when Ably cannot understand the request due to a malformed structure or other issues with the request format.

An example of this error is when a message is published while the connection is in a suspended state.

This error occurs when a request contains invalid content, such as incorrect data types or missing required objects. It is most likely caused by missing required fields or incorrect data formats when sending a request to Ably.

An example of this error is a missing field, such as a keyName in a token request.

This error occurs when an invalid value is sent in the request. It may be caused by either user input or the SDK sending incorrect parameters.

Additional examples of the 40003 error code output include:

• 40003: Excessive value for TTL

  This error occurs when the TTL set for a token parameter exceeds the maximum allowed value of 24 hours.

• 40003: Excessive value for TTL (revocation is enabled on this key)

  This error occurs when revocation is enabled, revocable tokens are limited to a TTL of 1 hour instead of 24 hours.

This error occurs when the API key or token used to initialize the library is invalid.

Resolution: The following steps can help resolve this issue:

• API key initialization:
  • Ensure you are the account’s admin or owner.
  • In your Ably dashboard to the API keys tab.
  • Use one of these API keys instead of your current one or create a new API key with the necessary permissions and privileges and use that to instance the SDK.
• Token initialization:
  • If you are using token authentication, ensure you are correctly requesting a valid token before using it with Ably.

This error occurs when a message is published with an invalid or mismatched connectionId.

Examples of this error are when:

• A client attempts to publish a message using a malformed connectionId.
• A client publishes a realtime message with a connectionId that does not match the currently active connection.
• A connection is identified, but the resolved clientId is missing or incorrect (due to authentication issues or an explicitly provided, but incorrect, clientId).

This error occurs when the message being published exceeds the maximum size allowed set by the limits for your current package.

This error occurs when a channel name does not meet the required format or contains invalid characters.

This error occurs when using the channel enumeration API and the state of the cluster changes between successive calls, causing a pagination sequence to become invalid. Note: This issue does not occur if the enumeration request is fully satisfied within the first response page.

This error occurs when a clientId is invalid due to disallowed characters or a mismatch between the clientId specified in the request and the one assigned in the authentication token.

Examples of this error are when:

• The client attempts to use * as a clientId, which is not allowed because * is used as a wildcard in capability expressions.
• A client tries to assume an ID of foo for an operation, but the token they are using specifies an ID of bar.

This error occurs when the SDK is unable to encode the message payload due to an unsupported data type.

An example of this error is when a client attempts to publish a payload that includes something that isn’t serializable by an Ably SDK.

Resolution: Try marshalling the payload as JSON or MsgPack before publishing.

This error occurs when the ID property in a DeviceDetails object, sent during a push notification registration request, is invalid. The ID must be a string.

This error occurs when the name property of a message is not a string. The name field is used to categorize messages within channels, and it must always be a string.

This error occurs when a request does not specify a protocol version or provides an invalid version in the request parameters of a Server-Sent Events (SSE) request. This error also occurs when a WebSocket connection to Ably specifies an invalid API version in the request parameters.

Resolution: Ensure that the request specifies a valid protocol version. Note: You will not see this error when using an Ably SDK, as SDKs automatically use valid versions.

This error occurs when a batch request partially fails, meaning that some operations succeed while others fail.

This error can occur for the following endpoints:

• Revoking tokens: POST/revokeTokens
• Publishing messages: POST/messages
• Retrieving presence data: GET/presence

The following example is a batch operation response that includes partial failures. The error field indicates that some requests within the batch were unsuccessful, while the batchResponse contains individual results for each operation:

{
  "error": "new ErrorInfo('Batched response includes errors', 40020, 400)",
  "batchResponse": "results"
}

Copy
Copied!

This error occurs when the requested resource is invalid or already exists. It is typically returned by requests to the Control API.

Examples of this error include attempting to create a resource that already exists or providing an invalid resource name.

Resolution: The following steps can help resolve this issue:

• Ensure that an app with the requested name does not already exist in your account. If it does, use a different name.
• Verify that the capabilities listed in the request are valid when creating an API key.

This error occurs when a publish request is malformed.

This error occurs when a published message contains arbitrary fields in the extras payload that are not allowed by the Ably service. The extras field is reserved for specific objects related to Ably.

Resolution: Place any additional data inside the headers field within extras. The headers field must be a flat object (map<string, string> or equivalent) with no nested structures. If using unenveloped Reactor rules, ensure that header names are in ASCII, as they will be converted into HTTP, AMQP, or other protocol headers.

The following example is a valid extras object:

JavaScript
JavaScript v2.7

const extras = {
  headers: {
    header1: 'value1',
    header2: 'value2'
  }
};

Copy
Copied!

This error occurs when an action cannot be performed due to a lack of authentication. There will be additional info in the message property about the reason the action could not be performed.

This error occurs when authentication credentials are invalid. The specific error message may provide further details about the cause.

An example of this error is when a signed token request is invalid due to a mismatched cryptographic signature (MAC does not match) or when the clientId specified in the Ably SDK does not match the clientId in the access token.

Resolution: Review your authentication setup and token request implementation. Ensure the following:

• The cryptographic signature (MAC) is correct – If a signed token request is invalid, Ably will reject it.
• The API key used to generate the token request is accurate – Double-check for missing or extra characters.
• The token request JSON is correctly formatted and unaltered, including:
  • keyName: Must match the API key used in the request.
  • clientId: If provided, it must match the one in the client constructor.
  • ttl: Must be an integer in milliseconds.
  • timestamp: Must be an integer in milliseconds.
  • capability: Must be stringified JSON, not raw JSON.
  • nonce: Must be a randomly generated string value.
  • mac: Must be correctly generated using the secret key.
• The clientId in the SDK matches the one in the token. If a clientId is provided in the token, it must align with the clientId set in the Ably client options.
• A clientId cannot be changed on an existing connection. Ensure consistency in authentication.
• For JWT authentication, confirm that clientId is correctly set in x-ably-clientId.

This error occurs when authentication credentials do not match the existing connection, causing the connection to enter the failed state.

Examples of this error include:

• Attempting to authenticate with an API key from a different app than the one used for the original connection
• Resuming a connection using credentials tied to a different app
• Calling auth.authorize with an API key that differs from the one originally used to establish the connection

This error occurs when an API key is used over a non-TLS (unencrypted) connection, which is not permitted due to security risks. API keys are long-lived credentials, making them more vulnerable if exposed. Unlike short-lived tokens, API keys remain valid indefinitely, meaning a compromised key presents a significant security risk.

Non-TLS transports can be inspected by network devices routing traffic between the client and Ably. Ably does not allow API key authentication over non-TLS connections. However, Ably supports basic authentication over TLS and token authentication over non-TLS connections.

Resolution: Select the appropriate authentication mechanism for your use case.

This error occurs when a signed token request sent to Ably is too old. Ably enforces timestamp validation to ensure TokenRequest remain valid for a limited time, reducing the risk of interception and misuse.

Resolutions: The following steps can help resolve this issue:

• Ensure that the authentication servers clock is accurate when generating signed token requests.
• If time synchronization is unreliable, set the queryTime ClientOptions object to true when initializing the Ably client. This ensures Ably’s server time is used.
• Do not cache signed token requests on the authentication server or client. Each token request must be freshly generated and used immediately.
• If using Next.js 13, prevent caching issues by setting revalidate to 0 or changing the request method from GET to POST using the authMethod ClientOption.

This error occurs when a signed token request has been used more than once. Ably enforces nonce (number used once) checks to ensure that each signed token request is unique, as a security measure.

Examples of this error include:

• A client sends a signed token request to Ably but does not receive the response due to network issues. If the client automatically retries the HTTP request in a fallback data center, Ably detects the duplicate nonce and rejects it.
• An authentication server caches and reuses signed token requests instead of generating a unique one for each request.
• A misconfigured authCallback function reuses the same token request on every invocation instead of generating a fresh one.
• The tokenRequest is not renewed. A new token request should be requested from your server at this point:

JavaScript
JavaScript v2.7

var tokenRequest = "<new-token-request>";
var ably = new Ably.Realtime({
  authCallback: function(tokenParams, callback) {
    // This is a mistake. The tokenRequest is not renewed.
       A new token request should be requested from your server at this point */
    callback(null, tokenRequest);
  }
});

Copy
Copied!

Resolution: The following steps can help resolve this issue:

• Ensure that each token request is unique and never cached by the authentication server or client.
• Always generate a new token request each time authCallback is invoked.
• If retrieving a token request over HTTP, prevent caching by using the Cache-Control header (no-cache, no-store, must-revalidate) or by adding a cache-busting query string parameter, where the number is regenerated for every request, for example, ?rnd=73849275.
• If network issues are suspected, check logs and debug the token request process to confirm proper request handling.

This error occurs when invalid authentication options (key or token) are provided to the Ably SDK, preventing successful authentication.

An example of this error is when no API key or token is supplied, or when an authentication request is made using a token to request another token, instead of an API key.

This error occurs when the peak connection limit for your account has been exceeded, preventing new connections from being established until existing ones disconnect.

This error occurs when your account has exceeded the allocated message limit based on your package. Once this limit is reached, further message publishing is blocked.

This error occurs when your account has exceeded the concurrent channel limit, preventing additional channels from being created.

Examples of this error are when the application attempts to open more channels than the account allows, causing new channel creation to be blocked. Also, during development, an implementation error or bug causes unintended channel creation, leading to the limit being reached.

Resolution: Detach unused channels to free up space for new ones.

This error occurs when your account has exceeded the allocated limits based on your package.

This error occurs when the application has reached the maximum number of integration rules set by the limits for your current package.

This error occurs when the application has reached the maximum number of API keys set by the limits for your current package.

This error occurs when the Ably API key used to initialize the SDK is no longer valid because it has been revoked by an admin of the application.

Resolution: The following steps can help resolve this issue:

• If you are an admin, go to the API keys tab in the Ably dashboard to check for valid keys. Use an existing valid key or create a new one with the necessary permissions.
• If you are not an admin, request a new API key from an administrator or obtain a token request generated with a valid key.

This error occurs when the Ably API key used to authorize a token revocation request does not match the key that originally issued the token.

Resolution: The following steps can help resolve this issue:

• Ensure that the public API key ID used in the request matches the key that originally issued the token.
• Verify that the keyname in the request path corresponds with the API key used for authentication.

This error occurs when attempting to authenticate with a token that has been revoked and is no longer valid.

Resolution: Ensure that you are using a valid, non-revoked. token for authentication. If needed, generate a new token and use it for authorization.

This error occurs when the authentication token has expired and is no longer valid for use.

An example of this error is when a client attempts to authenticate with a token that has exceeded its time-to-live (TTL).

Resolution: The following steps can help resolve this issue:

• Use authUrl or authCallback in your client configuration to enable automatic token renewal.
• If authUrl or authCallback is correctly configured, the client SDK will automatically renew the token when needed, so you may see this error temporarily before renewal occurs.

This error occurs when the provided token is not recognized as a valid Ably token, Ably JWT, or a JWT containing a valid Ably token.

An example of this error is when a JWT is incorrectly formatted or when an Ably token does not follow the expected structure, for example: <appId>.<randomBytes>. Any token that does not adhere to the correct format will not be recognized.

Resolution: Validate the token format before using it for authentication. If creating a JWT, use a standard JWT library to ensure correct generation. If using an Ably token, verify that it matches the expected format as returned from the requestToken endpoint.

This error occurs when the JWT. provided for authentication cannot be validated by Ably due to incorrect formatting, missing claims, or unsupported configurations.

This error occurs when the JWT provided for authentication cannot be validated by Ably. The specific reason for the failure will be available in the reason property of a ConnectionStateChange object or in an error response from a REST request.

Examples of this error include:

• Missing or invalid payload claims, such as iat (issued at) or exp (expiration).
• Using a deprecated or unsupported signing algorithm.
• Providing an empty string for x-ably-capability.
• Using an empty string or non-string value for x-ably-revocation-key.
• Missing kid (Key ID) when using JWT authentication with an API key.

This error occurs when the client does not have permission to perform the requested action.

An example of this error is when a token request includes an empty capability object, for example: ({}), meaning the client has no assigned permissions, or when the requested resource does not match the API key’s allowed capabilities.

Resolution: Ensure the API key supports the required capabilities for the requested action.

This error occurs when a non-identified client attempts to access a channel that requires an identified client. Each application’s channel namespaces configuration can be found in its application settings. By default, the identified namespace requires a client to be identified.

This error occurs when an authentication attempt using authUrl or authCallback fails due to a timeout, network issue, invalid token format, or another authentication error condition.

Examples of this error include when a TokenRequest callback times out after the default 10-second limit. Also, when he authUrl response is missing a Content-Type header has an unsupported Content-Type.

Resolution: The following steps can help resolve this issue:

• Check for network latency between the client and the authentication server.
• Ensure the authentication server returns a valid Content-Type header and one of the supported content types:
  • application/json
  • text/plain
  • application/jwt
• Additional error details can be found in the error.message field.

This error occurs when no authUrl or authCallback is provided in clientOptions when initializing the Ably REST or Realtime SDK.

Tokens have a set expiration time, and once expired, they are no longer valid for communication with Ably. If authUrl or authCallback is configured, the SDK will automatically request a new token before expiration, ensuring uninterrupted operation.

Resolution: Ensure that authUrl or authCallback is set in your client configuration. This allows the SDK to automatically request a new token before the current one expires.

This error occurs when a requested action is not permitted. It serves as the default response for forbidden actions and can be triggered by various issues.

The following are example for this error:

• Mismatched SDK versions, occurring if an application uses multiple versions of the Ably SDK, leading to inconsistencies in connections.
• A disabled account, indicating that the app belongs to an account that has been manually disabled by Ably.
• An incorrect URL for a private cluster.

By default, Ably apps require TLS for connections. This error occurs when a realtime SDK attempts to connect with TLS disabled (tls: false) while using token authentication.

Resolution: The following steps can help resolve this issue:

• Ensure that the tls ClientOption is set to true when connecting.
• If using API key authentication, note that this scenario will result in a 40103 error instead.

This error occurs when an app belonging to a dedicated (private) cluster is accessed using an incorrect endpoint. Enterprise customers with private clusters receive custom environment endpoints specific to their deployment.

An example of this error is when an app configured for a private cluster tries to connect via the default global endpoint.

Resolution: Check your custom environment settings for all connecting clients to ensure they point to the correct private cluster endpoints.

This error occurs when an app that belongs to a dedicated (private) cluster is accessed using an incorrect URL. This often happens when the correct environment is not specified when initializing a client library. Enterprise customers with private clusters receive custom environment endpoints specific to their deployment.

If a request arrives at an unexpected dedicated cluster or incorrect region, the account in that scope may be disabled, triggering this error.

An example of this error is when a client intended for a dedicated environment, such as acme, connects to the default global endpoint (realtime.ably.io) instead of the correct dedicated cluster endpoint (acme-realtime.ably.io). If the expected environment is not configured, requests may be rejected.

Resolution: Verify that all connecting clients are configured with the correct custom environment settings to ensure they are pointing to the intended dedicated cluster.

This error occurs when attempting to connect to an app for an account restricted to a specific region.

An example of this error is when a client attempts to connect to an Ably app restricted to the EU region but does not specify the EU environment in the SDK configuration.

Resolution: The following steps can help resolve this issue:

• Ensure you are configured with the correct environment for your region-restricted account.
• If your account has a regional constraint, you should have been provided with a custom environment to pass to the ClientOptions.
• Verify that your connection settings match the region assigned to your account.

This error occurs when the requested resource does not exist. This can apply to an Ably app, client, device, connection, API key, or token. The accompanying error message provides more details about the missing resource.

Examples of this error include:

• Attempting to authenticate using an Ably API key or token, but the specified appId cannot be found. This may happen if:
  • The appId is incorrect.
  • The appId does not exist in the current environment (especially in a custom deployment).
• Attempting to authenticate with an incorrect API key ID, which may be due to:
• An invalid API key ID.
• The key not being found in the specified environment.
• Incorrect formatting, particularly case sensitivity issues.

This error occurs when a limit on your account has been reached, preventing further requests until the limit resets. The duration of the limit depends on the type of rate limit:

• Instantaneous rate limits typically last up to six seconds before allowing message publishing to resume.
• Other limits may apply on an hourly or monthly basis.

An example of this error is when a client exceeds the maximum allowed message rate on a channel.

In the following example, the metric channel.maxRate represents the maximum rate of messages allowed to be published on a channel per second. The permitted rate is 5000 messages per second, but the client is attempting to publish 5015 messages per second, triggering the limit.

Rate limit exceeded; request rejected (nonfatal);
metric = channel.maxRate;
interval = 2018-01-05:10:10:3;
permitted rate = 5000;
current rate = 5015;
scope = channel:[YOUR APP ID]:[YOUR CHANNEL]
(status: 429, code: 42910) (code: 42910, http status: 429)

Copy
Copied!

Resolution: Wait for the rate limit period to reset before retrying. Optimize your message publishing to stay within allowed limits. Upgrade your package if higher throughput is required. Review your account limits to determine which restriction has been hit.

This error occurs when the number of messages sent per second exceeds the limit imposed on an account. To maintain service reliability for all users, Ably enforces usage limits at different levels, including monthly, hourly, and per-second thresholds.

This error occurs when multiple concurrent metadata REST requests are made to retrieve a list of active channels. The API is rate-limited, allowing only one in-flight call at a time. Additional concurrent requests will be rejected with this error.

Resolution: The following steps can help resolve this issue:

• Ensure that only one request is in progress at any given time.
• Implement request queuing or backoff strategies to avoid sending concurrent calls.
• If you require enhanced channel enumeration capabilities, visit this page to request access to the preview API.

This error occurs when a client has made too many requests within a 5-minute time window, causing the request to be rejected. The limit remains in effect for up to 30 seconds but may persist longer if request volume remains above the threshold from the same IP address.

This rate limit is in place to protect the Ably platform and is not expected during normal use.

This error occurs when there is an internal issue on an Ably channel.

This error occurs when there is an internal connection issue.

This error occurs when a connection request to Ably times out.

An example of this error is when a client attempts to publish a message to a channel, but the operation fails to complete within the allowed time.

Examples of this error include:

• Poor network conditions affecting connectivity.
• Improper usage of the Ably SDKs leading to unexpected delays.
• Temporary Ably server issues impacting response times.

This error occurs as a result of a request not being handled due to an internal routing error within the Ably service.

This error occurs when you previously activated a device for push notifications with a specific clientId, but then changed the clientId used for authentication. The mismatch causes the error because the push notification setup tracks the clientId and other details to prevent accidental changes between app launches. The clientId is linked to registrations, such as subscribing by clientId.

Resolution: If you need to change your client’s clientId, deactivate and reactivate the device. This process triggers an internal device.reset() call, which clears and resets the old device details.

This error occurs when a Reactor rule fails due to an issue with the configured endpoint. Ably attempts to send a POST request, but the response is unexpected or unsuccessful.

This error occurs when Ably sends a webhook to your server, but the server refuses or returns an unexpected response code. While Ably will retry the request multiple times, repeated failures indicate an issue on the server side.

This error occurs due to an internal error with the ingress worker. It is an unexpected issue that happens when the worker attempts to execute a rule but encounters an error during the process.

This error occurs when the rule worker is unable to access or retrieve data from either the outbox or nodes table in the database as expected.

An example of this error is misconfigurations in the database setup or inconsistencies between the provided configuration and the actual database schema or table names.

Resolution: The following steps can help resolve this issue:

• Verify the configuration of the outbox and nodes tables in the database to ensure they are correctly set up and match the rule definition.
• Check for database connectivity issues and confirm that the database is accessible.
• Ensure that the schema and table names align with the expected configuration.

This error occurs when a MongoDB Change Stream event does not contain the required _ablyChannel field after being processed through the Change Stream pipeline. This field is essential for identifying the channel where the change event message will be published.

Resolution: The following steps can help resolve this issue:

• Ensure that the _ablyChannel field is present at the root level of the change event.
• Avoid nesting it inside other sections, such as $fullDocument._ablyChannel.
• The field must be part of the main structure of the change event to allow proper identification.

This error occurs when the MongoDB Change Stream fails to start due to an invalid pipeline. An example of this error is when the pipeline syntax does not conform to MongoDB’s requirements or contains unrecognized operators.

Resolution: The following steps can help resolve this issue:

• Review the pipeline syntax for errors and ensure all operators are valid.
• Adjust the pipeline to match MongoDB’s accepted structure and syntax guidelines.

This error occurs when the MongoDB Change Stream cannot be resumed because the resume token document stored in MongoDB is not in the correct format.

Resolution: The following steps can help resolve this issue:

• Verify the format of the stored resume token document in MongoDB.
• Ensure the token meets the expected structure and format required for MongoDB Change Stream resumption.
• Refer to the MongoDB documentation for guidelines on properly storing and using resume tokens.

This error occurs when the MongoDB Change Stream resume token cannot be stored in the ably collection of the database.

Resolution: The following steps can help resolve this issue:

• Verify that the integration rule and MongoDB connection string are correctly configured.
• Ensure the database user has the necessary read and write permissions for the ably collection.
• Adjust permissions if needed to allow the token to be successfully stored.

This error occurs when the SDK is having trouble connecting to Ably, likely due to client-side network connectivity issues. Note: The SDK will automatically retry the connection after 30 seconds.

This error occurs when the SDK is having trouble connecting to Ably. This is likely due to client-side network connectivity issues, and has failed to establish a connection within 2 minutes. Note: The SDK will automatically retry the connection after 15 seconds.

This error occurs when the SDK is having trouble connecting to Ably, likely due to client-side network connectivity issues. Note: The SDK will automatically retry the connection after 15 seconds.

This error occurs when a connection resume attempt fails because the original connection has expired. This typically happens when the resume attempt occurs after the two-minute window has passed.

If this error occurs, the client establishes a new connection instead of resuming the old one. Any messages sent during the gap will be missed, unless channel persistence is enabled.

Resolution: Ensure that resume attempts occur within the two-minute window to successfully recover a connection. If message loss is a concern, use history to retrieve missed messages.

This error occurs when a realtime connection times out after waiting for the default 10-second realtimeRequestTimeout in certain Ably SDKs.

The request will be automatically retried by the SDK.

Resolution: If the client never connects to the primary or fallback endpoints, check any firewall rules that may be blocking access to Ably’s endpoints.

This error occurs when a browser connection upgrades from an HTTP (Comet) transport to WebSockets. It is logged by the client library when operations are performed on the older transport.

Resolution: the following steps can help resolve this issue:

• If this error only appears in logs, it is harmless and does not affect your application. No action is needed.
• If you receive this error as a response to a request, contact Ably support with relevant logs and details, and they will investigate the issue.

This error occurs when a connection has been closed and an operation is attempted on it, such as calling a channel or presence method, for example, channel.presence.update while the connection is still in a closed state.

Resolution: The following steps can help resolve this issue:

• Check the client’s connection state before performing operations to ensure the connection is active.
• If the connection is closed, reconnect before making requests to avoid this error.

This error occurs when an invalid connectionId is supplied.

Resolution: If you are seeing resumes failing in ably-js, this was a known bug in ably-js versions 1.2.30 through 1.2.33. Upgrading to the latest version of ably-js should resolve the issue.

This error occurs when the client library fails to obtain a token using the client-supplied authUrl or authCallback. It is raised when the request to the authentication server fails due to an error or exception in the callback.

This error occurs when a client exceeds the outbound subscribe message rate on a realtime connection.

Resolution: The subscriber will receive an UPDATE channel state change event, indicating that continuity is lost. Use the resume flag to determine whether to recover missing messages or handle the failure accordingly.

This error occurs when the maximum allowed rate of new connections for an account has been exceeded.

This error can occur when using the Comet transport, where a send or recv request is sent to the system but reaches a different frontend instance than the one hosting the connection. This can happen due to a disruption on a frontend instance.

Resolution: This is a non-fatal error, and no action is required. The transport will automatically drop and be re-initiated without any need for manual intervention.

This error occurs when a disconnected client attempts to resume a connection from a different site than the original connection. This typically happens when a client tries to resume via a fallback host.

Resolution: Channel message continuity will not be possible in this scenario. Any messages sent while the client was disconnected will need to be retrieved using history.

This error occurs when an application attempts to perform an operation on a channel that is in a state that does not permit it.

An example of this error is when an application tries to publish a message or attach to a channel that is in a failed state due to a prior error. As a result, the operation fails because actions cannot be performed on a channel in this state.

Resolution: The following steps can help resolve this issue:

• Ensure the channel is in an appropriate state before performing any operations.
• Use an Ably SDK to listen for channel state changes and handle operations accordingly.
• Implement state change callbacks to trigger the intended operation when the channel is in a valid state.

This error occurs when using the rewind feature with a specified time period, and the total number of messages within the selected timeframe exceeds the maximum limit that can be retrieved in a single request.

This error occurs when a channel fails to attach within the default 10-second timeout. It is most commonly encountered by clients with poor internet connections, where the ACK response to an ATTACH request does not return within the expected timeframe.

Note: In older versions of the ably-java SDK, this error was incorrectly assigned to error code 91200.

Resolution: Adjust the realtimeRequestTimeout or channelRetryTimeout (depending on the SDK) to a higher value to allow more time for the attachment process.

This error occurs when a Realtime client attaches to more channels than the account allows on a single connection. This happens when channels are attached but never explicitly detached, causing the limit to be reached.

Resolution: Review your channel limits and ensure that channels are explicitly detached when no longer needed.

This error occurs when the maximum rate of channel creation has been exceeded, across an account. Until the rate returns below the limit, new channels may not be created immediately. The Ably SDK will automatically retry every 10 seconds until the request succeeds.

This error occurs when a client attempts to enter the presence set of a channel without specifying a clientId.

A client can be identified in several ways:

• If using token authentication, ensure the token is associated with a clientId by setting the clientId field in tokenParams when creating a token request or requesting a token.
• If using basic authentication or token authentication with a wildcard clientId, set the clientId in the client options when initializing the Ably SDK.
• Specify a clientId at the time of entering presence using enterClient().

This error occurs when the maximum number of clients in the presence set for a channel has been reached, preventing additional clients from joining.

This is a client-side issue that occurs when an up-to-date presence set cannot be retrieved due to connection issues. It typically happens when calling presence.get() while the channel is in a suspended state, often caused by an interruption in the client’s internet connection.

Resolution: The following steps can help resolve this issue:

• Ensure the client has an active connection before calling presence.get().
• If an outdated presence set is acceptable, set waitForSync to false to retrieve the presence data even when out of sync.

This error occurs when calling spaces.get() without specifying a space name. The name parameter is required to retrieve a space.

Resolution: Ensure that a valid space name is provided when calling spaces.get():

JavaScript
JavaScript v2.7

const space = await spaces.get('mySpaceName');

Copy
Copied!

This error occurs when calling a function that requires the client to be entered into a space, but the client has not yet done so.

Resolution: Ensure that space.enter() is called before performing operations that require the client to be inside the space:

JavaScript
JavaScript v2.7

const space = await spaces.get('mySpace');
space.enter({
  username: 'Claire Lemons',
  avatar: 'https://slides-internal.com/users/clemons.png',
});

Copy
Copied!

This error occurs when an existing lock request is still pending or locked. Nested locks are not supported, so a new lock cannot be requested until the previous one is resolved.

This error occurs when a lock is already in the locked state, and a pending request did not override or release the lock.

This error occurs when a lock request invalidates an existing lock that was already in the locked state.