|
| 1 | +--- |
| 2 | +title: "Error 10000 - No error" |
| 3 | +meta_description: "Documentation for Ably error code 10000, which indicates successful operations, connection state transitions, or intentional message filtering." |
| 4 | +meta_keywords: "error 10000, no error, connection closed, channel attachment, connection state, message filtering" |
| 5 | +--- |
| 6 | + |
| 7 | +{/* Generated by: ably-os errors document-error-codes */} |
| 8 | +{/* Repository: https://github.com/ably/ably-os */} |
| 9 | +{/* Command: ./bin/ably-os errors document-error-codes 10000 */} |
| 10 | +{/* Generated: 2025-11-06T21:51:34.794Z */} |
| 11 | +{/* Sources: |
| 12 | + - Analysis: https://github.com/ably/ably-os/blob/b819713/output/error-codes/research/10000-analysis.md |
| 13 | + - Knowledge: https://github.com/ably/ably-os/blob/b819713/output/error-codes/research/10000-knowledge.md |
| 14 | + - Editorial notes: https://github.com/ably/ably-os/blob/b819713/src/prompts/errors/editorial-notes.md |
| 15 | +*/} |
| 16 | +{/* Key Approach: Multi-context documentation covering connection state management, normal operations, and filtering scenarios. Clarifies this is not typically an error condition requiring user action. */} |
| 17 | +{/* Citations: Complete source attribution with line numbers available at bottom of document */} |
| 18 | + |
| 19 | +This code represents a successful operation, normal state transition, or intentional filtering action rather than an error condition. |
| 20 | + |
| 21 | +| Error code | HTTP status code | Category | Retryable | |
| 22 | +| ---------- | ---------------- | -------- | --------- | |
| 23 | +| 10000 | 200 | Success/State Management | No | |
| 24 | + |
| 25 | +## Impact |
| 26 | + |
| 27 | +Error code 10000 typically indicates normal operation and does not prevent other operations from succeeding. The specific impact depends on the context in which you encounter it. |
| 28 | + |
| 29 | +## Troubleshooting |
| 30 | + |
| 31 | +The following are scenarios where you might encounter error code 10000: |
| 32 | + |
| 33 | +### Connection state restriction |
| 34 | + |
| 35 | +| Error code | Message | |
| 36 | +| ---------- | ------- | |
| 37 | +| 10000 | "Can't attach when not in an active state" | |
| 38 | + |
| 39 | +This occurs when attempting channel operations before the connection is established or when the connection is no longer active. |
| 40 | + |
| 41 | +{/* Source: Analysis finding from https://github.com/ably/ably-os/blob/b819713/output/error-codes/research/10000-analysis.md lines 26-31, Java SDK implementation */} |
| 42 | + |
| 43 | +To resolve this: |
| 44 | + |
| 45 | +Check your connection state before performing channel operations: |
| 46 | + |
| 47 | +<Code> |
| 48 | +```javascript |
| 49 | +const channel = ably.channels.get('your-channel'); |
| 50 | + |
| 51 | +// Wait for connection to be established |
| 52 | +ably.connection.on('connected', async () => { |
| 53 | + await channel.attach(); |
| 54 | + // Now safe to perform channel operations |
| 55 | +}); |
| 56 | +``` |
| 57 | +</Code> |
| 58 | + |
| 59 | +{/* Source: Based on connection state management patterns from Ably connection documentation */} |
| 60 | + |
| 61 | +<Aside data-type="note"> |
| 62 | +With default settings (queueMessages: true), you typically don't need to wait for connection establishment. Messages are automatically queued and sent when the connection becomes active. Only check connection state when you've explicitly disabled message queueing or need immediate confirmation of delivery. |
| 63 | +</Aside> |
| 64 | + |
| 65 | +{/* Source: Editorial notes guidance on connection states from https://github.com/ably/ably-os/blob/b819713/src/prompts/errors/editorial-notes.md lines 145-209 */} |
| 66 | + |
| 67 | +### Mobile app lifecycle transitions |
| 68 | + |
| 69 | +| Error code | Message | |
| 70 | +| ---------- | ------- | |
| 71 | +| 10000 | "Can't attach when not in an active state" | |
| 72 | + |
| 73 | +This commonly occurs in mobile applications when the app returns from background state and attempts to resume operations before the connection is re-established. |
| 74 | + |
| 75 | +{/* Source: Support case from https://github.com/ably/ably-os/blob/b819713/output/error-codes/research/10000-knowledge.md lines 103-109, EA customer issue */} |
| 76 | + |
| 77 | +To resolve this: |
| 78 | + |
| 79 | +Handle app lifecycle events and wait for connection before resuming operations: |
| 80 | + |
| 81 | +<Code> |
| 82 | +```javascript |
| 83 | +// React Native example |
| 84 | +import { AppState } from 'react-native'; |
| 85 | + |
| 86 | +AppState.addEventListener('change', (nextAppState) => { |
| 87 | + if (nextAppState === 'active') { |
| 88 | + // Wait for connection to be re-established |
| 89 | + if (ably.connection.state !== 'connected') { |
| 90 | + ably.connection.once('connected', () => { |
| 91 | + // Resume operations |
| 92 | + resumeChannelOperations(); |
| 93 | + }); |
| 94 | + } |
| 95 | + } |
| 96 | +}); |
| 97 | +``` |
| 98 | +</Code> |
| 99 | + |
| 100 | +{/* Source: Based on mobile app lifecycle best practices and support case context from knowledge file */} |
| 101 | + |
| 102 | +### Connection closed by client |
| 103 | + |
| 104 | +| Error code | Message | |
| 105 | +| ---------- | ------- | |
| 106 | +| 10000 | "Connection closed by client" | |
| 107 | + |
| 108 | +This indicates the connection was intentionally closed by your application. This is normal behavior and not an error condition. |
| 109 | + |
| 110 | +{/* Source: Analysis finding from https://github.com/ably/ably-os/blob/b819713/output/error-codes/research/10000-analysis.md lines 15-20, .NET SDK implementation */} |
| 111 | + |
| 112 | +No action is required unless the disconnection was unintended. |
| 113 | + |
| 114 | +### Message filtering |
| 115 | + |
| 116 | +| Error code | Message | |
| 117 | +| ---------- | ------- | |
| 118 | +| 10000 | "Discarding message; not local origin" or "Message discarded by perMessageTransform" | |
| 119 | + |
| 120 | +This occurs on the server side when messages are intentionally filtered by integration rules or transformation logic. This is expected behavior when filtering rules are configured. |
| 121 | + |
| 122 | +{/* Source: Analysis finding from https://github.com/ably/ably-os/blob/b819713/output/error-codes/research/10000-analysis.md lines 36-55, realtime server implementation */} |
| 123 | + |
| 124 | +If messages are being filtered unexpectedly, review your integration configuration in the Ably dashboard. |
| 125 | + |
| 126 | +## Related errors |
| 127 | + |
| 128 | +The following errors are related to connection state management: |
| 129 | + |
| 130 | +| Error code | Description | |
| 131 | +| ---------- | ----------- | |
| 132 | +| [80000 - Connection failed](/docs/platform/errors/codes/80000) | Occurs when connection cannot be established, unlike 10000 which indicates the connection state is preventing operations. | |
| 133 | +| [80002 - Connection suspended](/docs/platform/errors/codes/80002) | Connection enters suspended state after extended disconnection, requiring full reconnection unlike the temporary state indicated by 10000. | |
| 134 | +| [80003 - Unable to send message](/docs/platform/errors/codes/80003) | Similar to 10000 but specifically for message publishing when queueing is disabled. | |
| 135 | + |
| 136 | +## Resources |
| 137 | + |
| 138 | +* [Connection state documentation](https://ably.com/docs/connect) |
| 139 | +* [Channel attachment and lifecycle](https://ably.com/docs/channels) |
| 140 | +* [Mobile app best practices](https://ably.com/docs/best-practice-guide) |
| 141 | + |
| 142 | +## Need further help? |
| 143 | + |
| 144 | +Contact [Ably support](https://ably.com/support) if you're still experiencing issues after trying the steps listed above. |
| 145 | + |
| 146 | +You'll need to provide: |
| 147 | + |
| 148 | +* Your account ID and app ID. |
| 149 | +* The full error message including the error code. |
| 150 | +* Steps to reproduce the issue. |
| 151 | +* Any relevant code snippets (without any sensitive credentials). |
| 152 | +* The SDK and version you're using. |
| 153 | + |
| 154 | +### Additional resources |
| 155 | + |
| 156 | +* [Connection state transitions](https://ably.com/docs/connect/states) |
| 157 | +* [Client options documentation](https://ably.com/docs/api/realtime-sdk#client-options) |
| 158 | + |
| 159 | +{/* =============================================== */} |
| 160 | +{/* INTERNAL DOCUMENTATION (NOT RENDERED) */} |
| 161 | +{/* =============================================== */} |
| 162 | + |
| 163 | +{/* SOURCES USED: |
| 164 | +- Analysis File: https://github.com/ably/ably-os/blob/b819713/output/error-codes/research/10000-analysis.md |
| 165 | +- Knowledge File: https://github.com/ably/ably-os/blob/b819713/output/error-codes/research/10000-knowledge.md |
| 166 | +- Editorial Notes: https://github.com/ably/ably-os/blob/b819713/src/prompts/errors/editorial-notes.md |
| 167 | +- No pre-existing documentation found |
| 168 | +*/} |
| 169 | + |
| 170 | +{/* CONTENT DECISIONS: |
| 171 | +- Structure B used due to multiple distinct contexts for this error code |
| 172 | +- Emphasized that 10000 is not typically an error requiring action (lines 23-24) |
| 173 | +- Focused on connection state restriction as primary user-facing scenario (lines 26-31 from analysis) |
| 174 | +- Included mobile app lifecycle guidance based on EA support case (lines 103-109 from knowledge) |
| 175 | +- Mentioned message filtering but de-emphasized as server-side internal behavior (lines 36-55 from analysis) |
| 176 | +- Applied editorial notes guidance about connection states and default queueing behavior (lines 145-209 from editorial notes) |
| 177 | +- No code examples for message filtering as it's server-side only |
| 178 | +- Did not include frequency claims per editorial notes guidance on avoiding speculation |
| 179 | +*/} |
| 180 | + |
| 181 | +{/* ATTRIBUTION BY SECTION: |
| 182 | +- Overview: Based on official definition "no error" from analysis lines 9 and knowledge lines 21-23 |
| 183 | +- Connection State Restriction: |
| 184 | + - Issue: Java SDK implementation from analysis lines 26-31 |
| 185 | + - Solution: Standard connection state management pattern from Ably documentation |
| 186 | + - Note about queueing: Editorial notes lines 145-209 |
| 187 | +- Mobile App Lifecycle: |
| 188 | + - Issue: EA customer support case from knowledge lines 103-109 |
| 189 | + - Solution: Mobile app lifecycle best practices |
| 190 | +- Connection Closed: |
| 191 | + - .NET SDK implementation from analysis lines 15-20 |
| 192 | +- Message Filtering: |
| 193 | + - Realtime server implementation from analysis lines 36-55 |
| 194 | +- Related Errors: Selected based on connection state relationship |
| 195 | +*/} |
| 196 | + |
| 197 | +{/* URL VALIDATION NOTE: 2025-11-06T21:51:34.794Z */} |
| 198 | +{/* External URLs: 6 standard Ably documentation URLs (could not validate due to network restrictions, but all follow documented patterns) | Exempted internal: 3 error code links */} |
| 199 | + |
| 200 | +{/* IMPROVEMENT INSTRUCTIONS: |
| 201 | +To improve this error code documentation: |
| 202 | +1. First approach: Update editorial-notes.md in ably-os repository with specific guidance for error 10000 |
| 203 | +2. Regenerate: Run `./bin/ably-os errors document-error-codes 10000 --force` |
| 204 | +3. For broader improvements: Review and update ably-os prompt templates |
| 205 | +4. Context: See https://github.com/ably/ably-os/blob/b819713/docs/ERROR_COMMANDS_GUIDE.md |
| 206 | +5. Source repository: https://github.com/ably/ably-os |
| 207 | +*/} |
0 commit comments