Page unavailable? Copy its Markdown and paste it into your chat.
Errors, conflicts and retries
Recover from a failure without widening access or duplicating writes.
Reviewed · 2026-09-26 / Ridian
Classify before retrying
Section titled “Classify before retrying”| Situation | Recovery |
|---|---|
| Invalid input or unknown timezone | Correct the request; ask the user for missing intent |
| Expired/revoked authorization | Follow refresh or reconnect; do not broaden access |
| Excluded calendar or unsupported action | Change the workflow or obtain the appropriate explicit grant |
| Concurrent edit / ETag conflict | Read the current event, compare, then decide |
| Provider throttling or temporary failure | Back off; respect retry guidance when supplied |
| Timeout after a possible write | Treat the result as unknown; inspect or retry with the same operation key |
Next steps in MCP results
Section titled “Next steps in MCP results”MCP tool errors are returned as tool results with isError: true, not as HTTP errors; only a missing or expired sign-in answers with HTTP 401. Each error names the cause class (for example revoked provider access, a missing permission for this area, or invalid input) and a next step. When the user has to act in Ridian, the text includes a direct link to the matching page, such as Connections or AI & Assistants. A write error only says “Nothing was changed” when the failure happened before anything was written; otherwise it asks to check the current state before retrying.
Successful results can add a short note when accounts were excluded, for example because a provider grant expired or an area was not enabled. The structured output is unchanged; the note is an additional text block.
Preserve operation identity
Section titled “Preserve operation identity”A creation retry is the same intended operation. Keep its original requestId and payload. A new key expresses a new creation and may create a duplicate. Changed input with an old key can be rejected as a conflict. Do not promise exactly-once behavior beyond the documented provider path.
Updates and deletes have provider-specific concurrency constraints. CalDAV uses strong ETags and conditional requests to avoid silently overwriting another editor. A missing object after deletion can be reported as already gone, not a newly executed delete.
Incomplete availability is not free time
Section titled “Incomplete availability is not free time”If a requested calendar cannot be checked, the client must not claim that all calendars are free. An empty provider result, a permission denial and a failed provider read have different meanings.
Diagnose without copying content
Section titled “Diagnose without copying content”Capture request ID when provided, operation, provider, time and sanitized error. Do not log tokens, app passwords, full provider responses or event descriptions. The current REST interface does not yet offer the full error/limit contract planned for partner integrations; handle the actual response instead of assuming a future schema.