Skip to content

Troubleshooting

This chapter describes errors that occur when using Myra AI Workspace, including their causes and the steps to resolve them.

Error: 429 rate_limited

Description

The gateway returns HTTP 429 with code rate_limited when the number of requests in the current sliding window exceeds the configured limit. The limit can be set at gateway level (applies to all traffic) or per authentication token (applies to a single caller). The gateway enforces rate limits before any upstream provider call is made. The response includes three headers: X-RateLimit-Limit (the configured limit), X-RateLimit-Remaining (always 0 when blocked), and Retry-After (the window duration in seconds).

Resolution

Proceed as follows to resolve the error:

  1. Read the Retry-After header in the HTTP 429 response.
  2. The header contains the window duration in seconds. Waiting at least this long before retrying is sufficient.
  3. Implement exponential backoff in the calling application before retrying.
  4. The retry delay increases with each subsequent attempt, reducing burst pressure on the gateway.
  5. Open the Gateways view, click on the Open → button of the gateway, then click on the Edit button in the Gateway card header.
  6. The Edit Gateway: modal opens.
  7. Increase the value in the Rate Limit (req) text field or the Rate Window (s) text field to raise the gateway-level limit, then click on Save Changes.
  8. The updated rate limit applies to all subsequent requests.
  9. To increase a per-token limit, open the Users view, open the user record, create a new token from the Tokens card with a higher rate-limit setting, and replace the previous token in the calling application.
  10. The new token applies its rate limit to subsequent requests.

-> The gateway accepts requests again once the current window elapses or after the limit has been raised.

💡 Note: rate_limited is also returned when the upstream provider returns a 429 (its own rate limit), relayed as 429 rate_limited with X-AIG-Rate-Limited: true and the provider's Retry-After. Raising the gateway or per-token limit does not fix that origin — the fix is at the provider (a higher provider quota, or routing to a different provider). Distinguish the two by the X-AIG-Rate-Limited header.

Error: 429 quota_exceeded

Description

The gateway returns HTTP 429 with code quota_exceeded when the cumulative spend for an authentication token, a tenant, or a gateway has reached its configured budget. All three budget levels are evaluated independently on every request. The error message identifies exactly which budget scope was exhausted, states the configured budget and the current spend, and provides the API endpoint needed to increase the budget or reset the spend of the current period. The HTTP 429 response also carries a Retry-After header (whole seconds) set to the time until the budget period resets. A lifetime (total) budget cap never resets, so no Retry-After header is sent — the message states the cap is fixed and a retry cannot clear it. The one exception is a self-serve workspace's monthly allowance (stored with a total period but refilled every ~30 days): its 429 points Retry-After at the next allowance reset, and omits it only when no reset is scheduled (grace, inactive, or cancelling at the period end with no allowance reset before it) — see Error codes and Billing.

Resolution

Proceed as follows to resolve the error:

  1. Read the message field in the HTTP 429 response body to identify the affected scope (token, tenant, or gateway) and the API endpoint.
  2. The message states the budget, the current spend, and two corrective actions.
  3. Choose one of the following actions based on the scope:
  4. To reset spend immediately: call DELETE /admin/v1/gateways/{id}/budget, DELETE /admin/v1/tenants/{id}/budget, or DELETE /admin/v1/users/{id}/budget (the user endpoint resets every token of the user) as indicated in the message. The gateway and tenant resets are platform-admin only — a tenant admin receives 403 and must ask a platform operator; the user-token reset is unaffected.
  5. To increase the budget: call PATCH on the relevant resource with an updated budget_usd value.
  6. Alternatively, navigate to the Gateways or Users section in the admin UI, open the affected record, and use the Reset budget button or update the Budget (USD) field.
  7. The budget reset takes effect immediately.

-> The gateway accepts requests again once the budget has been increased or the spend counter has been reset.

Error: 502 all_providers_failed

Description

The gateway returns HTTP 502 with code all_providers_failed when every provider in the routing chain — the primary provider and all configured fallback providers — has returned errors or timed out. The primary provider is retried up to retry_count times on HTTP 5xx responses. Each fallback provider is attempted once in order. HTTP 4xx responses from a provider terminate the chain immediately without attempting further fallbacks.

Resolution

Proceed as follows to resolve the error:

  1. Check the request log in the app (Settings → Request Logs) for the failed request to identify which providers were attempted and what status codes they returned.
  2. The log entry shows the primary provider, fallback providers, and the HTTP status code received from each.
  3. Check the operational status of the affected providers on their respective status pages.
  4. Ongoing provider outages confirm that the error originates outside the gateway.
  5. Navigate to Gateways, open the affected gateway, and verify that BYOK keys are stored for every provider in the fallback chain.
  6. A missing key for a fallback provider causes a 4xx authentication failure, which halts the fallback chain.
  7. Add additional fallback providers to the routing rule if the current chain does not provide sufficient redundancy.
  8. Open the routing rule, add entries to the Fallbacks list, and save.
  9. Enable the circuit breaker on the gateway to prevent retry cycles during sustained provider outages.
  10. Set circuit_breaker.enabled to true in the gateway configuration.

-> The gateway returns a successful response once at least one provider in the chain is reachable and authenticated.

Error: 400 guardrail_blocked

Description

The gateway returns HTTP 400 with code guardrail_blocked when a guardrail in the pipeline matches the request or response content and its action is set to block. The error message identifies the guardrail name and the specific pattern or harm category that triggered the block. In streaming mode, the gateway returns HTTP 200 with a synthetic SSE stream containing the block message, because some streaming clients do not handle non-200 responses on streaming connections.

Resolution

Proceed as follows to resolve the error:

  1. Read the message field in the response body to identify which guardrail blocked the request and which pattern or category matched.
  2. For streaming responses, inspect the content of the first SSE data chunk.
  3. Review the content of the request or response that triggered the block.
  4. Remove or rephrase the matched content and retry.
  5. If the block is a false positive, navigate to the Guardrail Builder for the affected gateway and adjust the matching guardrail.
  6. For a regex or keyword guardrail: update or remove the pattern that caused the false match.
  7. For a Tier 2 guardrail (Presidio, Prompt Guard): consider changing the action from block to flag for entity types with a high false-positive rate.
  8. Save the updated guardrail configuration.
  9. The new configuration applies to all subsequent requests.

-> The gateway forwards the request to the provider once the content no longer matches any guardrail configured with a block action.

Error: 401 unauthorized

Description

The gateway returns HTTP 401 on the inference path (/v1/...) when a request does not carry a usable gateway token, but with a distinct code per cause: a missing or malformed token returns unauthorized (Missing or invalid gateway token); an expired token returns token_expired, with an actionable message that names the expiry and points to regenerating it under Gateways → Tokens; a revoked token returns token_revoked. Branch on the code, not the shared 401 status, so a scheduled agent or client stuck on a stale token gets a concrete next step instead of an opaque 401. This section covers inference authentication; admin API (/admin/v1/...) authentication is handled separately.

Resolution

Proceed as follows to resolve the error:

  1. Verify that the request carries the token in one of the accepted headers — x-aig-token, Authorization: Bearer <token>, or x-api-key — with a valid value.
  2. Check that no whitespace or truncation has been introduced when copying the token.
  3. Open your Profile page (user-block menu at the bottom of the left sidebar → Account → Profile) to confirm the token is active and has not been revoked.
  4. Revoked tokens show a revoked status and cannot be reinstated.
  5. If the token has been revoked or lost, create a new token on the Profile page.
  6. Click on the New Token button, configure the required rate limit and budget fields, and save.
  7. The new token value is displayed once on creation.
  8. Update the calling application or integration with the new token value.
  9. The token is passed in the x-aig-token header on every request.

-> The gateway accepts requests once a valid, active token is present in the request header.

Error: 403 forbidden (IP allowlist)

Description

The gateway returns HTTP 403 with code forbidden when the source IP address of the request is not included in the configured IP allowlist of the gateway. This applies when an IP allowlist has been configured on the gateway; gateways without an IP allowlist accept requests from any source address. The allowlist accepts both IPv4 and IPv6 CIDR ranges.

Resolution

Proceed as follows to resolve the error:

  1. Confirm the source IP address of the request by checking the calling system or reading the IP from the gateway request log.
  2. The log entry includes the client IP address.
  3. Inspect the current allowlist in the Edit Gateway dialog, under Search & tools → IP allowlist (each row is one CIDR entry). You can also read ip_allowlist from the config via GET /admin/v1/gateways/<id>.
  4. Add the source IP address or CIDR range — add a row in the IP allowlist editor (CIDR notation, for example 203.0.113.10/32 for a single IPv4 address, or an IPv6 range), or PATCH the config via the Admin API:

curl -X PATCH "https://<your-gateway-host>/admin/v1/gateways/<id>" \
  -H "Content-Type: application/json" \
  -d '{"config": {"ip_allowlist": ["203.0.113.10/32", "198.51.100.0/24"]}}'
4. If the calling system uses dynamic IP addresses, consider using a NAT gateway or proxy to provide a stable egress IP, then add that IP to the allowlist.

-> The gateway accepts requests from the source IP address once it is included in the allowlist.

Error: Circuit breaker open

Description

When the circuit breaker is enabled on a gateway and a provider accumulates failures at or above the configured failure_threshold within the window_sec interval, the circuit breaker transitions to the open state for that provider. While open, the gateway skips that provider entirely and proceeds directly to the next entry in the fallback chain. If no fallback is available, the request fails with 502 all_providers_failed. After the cooldown_ms period elapses, the circuit breaker transitions to the half-open state and admits requests again to test recovery. A probe is judged on its delivered outcome: only an attempt that actually returns an answer closes the breaker. An attempt that returns 200 with no answer, breaks mid-stream, or is cancelled by the client proves nothing and leaves the breaker under probation, where the next real failure re-opens it and restarts the cooldown.

Resolution

Proceed as follows to resolve the error:

  1. Check the circuit breaker status for the affected gateway by calling GET /admin/v1/gateways/{id}/circuit-breaker or by opening the gateway detail page in the admin UI.
  2. The response lists each provider with its current state (open, half_open, or closed), the failure count, and the time the breaker opened. failures reads 0 for a breaker that has been open for a while — the counter only accumulates while the breaker is closed. Use the [circuit_breaker] transition= log lines (they carry a reason=) or the aig_circuit_breaker_transitions_total metric to see why it opened and whether it keeps re-opening.
  3. Check the operational status of the affected provider on its status page.
  4. If a provider outage is confirmed, wait for the provider to recover; the circuit breaker probes automatically after cooldown_ms elapses.
  5. Verify that fallback providers are configured in the routing rule for the affected gateway.
  6. Open the routing rule and confirm entries exist in the Fallbacks list, each with a valid BYOK key stored.
  7. If the circuit breaker opened due to a configuration error (for example, an incorrect BYOK key), correct the key in the BYOK key vault, then wait for the cooldown period to expire.
  8. Once the provider answers normally again, the first probe that delivers an answer transitions the breaker back to closed. If the provider returns 200 with an empty answer, the breaker deliberately stays shed — check the reason= on the transition=half_open->open log line.
  9. To adjust sensitivity, update failure_threshold, window_sec, or cooldown_ms in the gateway configuration.
  10. Raise failure_threshold or increase window_sec to reduce sensitivity to transient errors.

-> The gateway resumes routing to the provider once a probe request delivers an answer and the circuit breaker returns to the closed state.

Error: Tier 2 guardrail sidecar unavailable

Description

Tier 2 guardrails (NLP PII Detector, Prompt Guard, PII Protector) make an HTTP call to a locally hosted sidecar service within Myra's certified infrastructure. If the sidecar service is unavailable — due to a deployment issue, resource exhaustion, or network isolation — the gateway cannot complete the Tier 2 guardrail check. The behaviour when this occurs is controlled by the fail_open setting on each Tier 2 guardrail. When fail_open is true, the request passes through as if no match occurred; when fail_open is false, the request is blocked with 503 guardrail_unavailable. Most Tier 2 detectors default to fail_open: true, but the Prompt Injection detector is the exception — it defaults to fail-closed, so its sidecar outage blocks the request rather than letting it through.

Resolution

Proceed as follows to resolve the error:

  1. Check the request log in the admin UI for affected requests and look for guardrail verdict fields (blocked, blocked_by, detectors_fired — the legacy log-field name for the guardrails that fired) to confirm which sidecar was unreachable.
  2. Requests that passed through with fail_open: true will not have a block verdict; the absence of a Tier 2 verdict in the log indicates the sidecar was skipped.
  3. Verify that the sidecar service is running and reachable within the infrastructure of Myra Security.
  4. Contact Myra Security support if the sidecar deployment is managed by Myra.
  5. If the sidecar is self-managed, check the deployment logs and resource allocation for the affected sidecar (Presidio, Prompt Guard, or PII Protector container).
  6. Restart the sidecar service if it has crashed or become unresponsive.
  7. Review the fail_open setting for the affected Tier 2 guardrail in the Guardrail Builder.
  8. If the guardrail is a hard security dependency, set fail_open to false to block requests when the sidecar is unavailable rather than allowing uninspected traffic through.
  9. Save the updated guardrail configuration.
  10. The change applies to all subsequent requests.

-> The Tier 2 guardrail resumes normal operation once the sidecar service is reachable and responding to health checks.

Error: 404 tenant_not_found

Description

The gateway returns HTTP 404 with code tenant_not_found when the URL path resolves to a tenant or gateway that does not exist or has been deleted. The path format is /v1/<TENANT_SLUG>/<GATEWAY_SLUG>/<PROVIDER>/...; both slugs must match an existing record.

Resolution

Proceed as follows to resolve the error:

  1. Verify the tenant slug and gateway slug in the request URL.
  2. The slugs are case-sensitive.
  3. Open the Gateways view in the admin panel and confirm the gateway exists and is owned by the expected tenant.
  4. If the gateway has been deleted, create a new one or restore the URL to an active gateway.

-> The gateway accepts requests once the URL resolves to an existing tenant and gateway.

Error: 502 provider_error

Description

The gateway returns HTTP 502 with code provider_error for an upstream provider failure the gateway cannot safely retry or fall back from — for example a mid-stream provider error on a buffered or PII-masked tool-loop turn, or a web-search leg failure. It is distinct from all_providers_failed: routing-chain exhaustion — the primary and every configured fallback failing, or a single provider with no fallbacks — always terminates as all_providers_failed, never provider_error.

Resolution

Proceed as follows to resolve the error:

  1. Read the message field of the response body. It contains the upstream status and the provider name.
  2. Check the operational status of the affected provider on its public status page.
  3. If the provider is operational, verify the BYOK key for that provider is correct and not rate-limited at the provider side.
  4. Review the Routing rules card on the gateway detail view. Consider reordering the fallback chain so a more reliable provider runs first.

-> The gateway returns successful responses once the affected provider recovers or the routing rule selects a different upstream.

Error: 400 invalid_request

Description

The gateway returns HTTP 400 with code invalid_request when the request body is malformed JSON, when required fields are missing, or when the body fails the basic shape check before being forwarded to the provider.

Resolution

Proceed as follows to resolve the error:

  1. Read the message field of the response body. It states the specific parsing or validation problem.
  2. Validate the request body as JSON. Check for missing braces, trailing commas, and unescaped quotes inside string values.
  3. Confirm the body contains the required fields for the chosen endpoint:
  4. model and messages are required for the OpenAI-compatible chat-completions endpoint.

-> The gateway accepts the request once the body parses as JSON and contains every required field.

Error: context_overflow (413) and context_length_exceeded (400)

Description

When the input token count exceeds the model's context window, the gateway returns one of two distinct codes: the gateway's own pre-flight estimate refuses the request with 413 context_overflow before dispatch, while a request that passes pre-flight but the upstream provider then rejects returns 400 context_length_exceeded. Both mean "the input is too long"; branch on the code.

The pre-flight estimate (the context_overflow path) is approximate (text is counted at roughly 3.5 characters per token) and accounts for image and document (PDF) attachments at a fixed per-attachment cost, so an attachment-heavy request can exceed the window even when its visible text is short. To avoid rejecting a request that would actually fit, the hard pre-flight block uses a deliberately low per-image cost (a false rejection has no recovery); the usage indicator and compaction trigger use a higher, conservative cost. If an attachment-heavy request still exceeds the real window, the upstream provider's own rejection is caught and re-emitted as context_length_exceeded, so nothing slips through silently.

Resolution

Proceed as follows to resolve the error:

  1. Read the message field of the response body. It states the estimated input token count and the model's maximum.
  2. Reduce the size of the conversation: remove long system prompts, drop older turns, remove image attachments, or split the request into multiple smaller calls.
  3. For Anthropic gateways, enable Context compaction in the gateway configuration. Older conversation turns are summarised automatically when the input approaches the threshold. See Context compaction.
  4. If a different model with a larger context window is acceptable, route the request to that model through a routing rule or by changing the model field.

-> The gateway forwards the request once the input fits within the model's context window.

Error: 500 internal_error

Description

The gateway returns HTTP 500 with code internal_error for unexpected exceptions that bypass the typed-error path. The response is a generic message; the detailed cause is logged server-side.

Resolution

Proceed as follows to resolve the error:

  1. Open the Request logs view and locate the failed request by timestamp.
  2. Note the request ID and the gateway slug.
  3. Contact Myra Security support and provide the request ID and the timestamp.

-> Internal errors require server-side log inspection. Once the underlying cause is identified, the fix is deployed by Myra Security.

Error: 504 request_timeout

Description

The gateway returns HTTP 504 with code request_timeout when a request does not complete within the gateway's time budget. The accompanying message is The request took too long to complete. Try a simpler request, narrow the scope, or turn off web search. This most commonly occurs on requests that fan out into several provider round-trips — for example a web search that triggers multiple tool calls — or on very large prompts and slow upstream responses.

Resolution

Proceed as follows to resolve the error:

  1. Simplify the request: ask for less in a single turn, or narrow the scope of the question.
  2. If web search is enabled for the chat, turn it off and resend.
  3. Web search adds several provider round-trips that can exceed the time budget.
  4. Reduce the size of the input by dropping older turns or removing large attachments, so the provider responds faster.
  5. Retry the request.
  6. Transient upstream slowness often clears on the next attempt.

-> The gateway returns a successful response once the request completes within the time budget.

Error: 413 request_too_large

Description

The gateway returns HTTP 413 with code request_too_large as a terminal re-label when a request fails across every provider and is almost certainly too large for the upstream models to process — typically because of oversized or re-sent attachments. The accompanying message is The request could not be processed by any provider. If it contains large attachments it is likely too big for the model — remove attachments or start a new chat. The code is only used once all provider attempts have genuinely failed, so it never rejects a request that would have succeeded.

Resolution

Proceed as follows to resolve the error:

  1. Remove or shrink the attachments on the request.
  2. Large or repeatedly re-sent files are the most common cause.
  3. Start a new chat to drop accumulated history and attachments carried over from earlier turns.
  4. If the text content itself is large, split it into several smaller requests.

-> The gateway forwards the request once it is small enough for a provider to accept.

Error: 400 web_search_not_supported

Description

The gateway returns HTTP 400 with code web_search_not_supported when web search is enabled for the chat but the selected model does not support it. The accompanying message is The selected model rejected web search. Disable web search for this chat or pick a different model.

Resolution

Proceed as follows to resolve the error:

  1. Turn off web search for the chat and resend the request.
  2. Alternatively, select a model that supports web search.

-> The request sends once web search is disabled or a web-search-capable model is selected.

Error: 400 model_capability_mismatch

Description

The gateway returns HTTP 400 with code model_capability_mismatch when the routed model cannot run a capability the request requires — file tools, web search, or vision (image input). The accompanying message is The selected model cannot run this request's tools. Pick a different model, or disable web search / remove attachments and retry.

Resolution

Proceed as follows to resolve the error:

  1. Pick a different model that supports the required capability.
  2. Alternatively, remove what the model cannot handle: disable web search, or remove the attachments or images from the request.

-> The request sends once the selected model supports every capability the request needs.

Error: 424 provider_key_missing

Description

The gateway returns HTTP 424 with code provider_key_missing when the selected model routes to a provider that requires an API key, but no key is stored for this gateway (and the requested key alias). The accompanying message is No API key is configured for this provider on this gateway. Add a provider key in the gateway settings. This is a configuration gap — a missing credential — not a gateway fault, and it is returned before any upstream call. It is distinct from configuration_error (500), which signals a malformed gateway configuration.

Resolution

Proceed as follows to resolve the error:

  1. Open the affected gateway's provider settings and confirm which provider the selected model routes to.
  2. Add (or activate) an API key for that provider. If the request set an x-aig-byok-alias header, store the key under that exact alias — the gateway never falls back to the default key for an unknown alias.
  3. Retry the request.

-> The request succeeds once a valid provider key is stored for the gateway.

Error: 424 managed_model_not_enabled

Description

The gateway returns HTTP 424 with code managed_model_not_enabled when the selected model is a Myra-provided (Platform Key) model that this gateway has not enabled — there is no managed grant for it (or it was granted without the required workspace budget), and no own provider key on the default alias covers it either. The accompanying message is This is a Myra-provided model. Enable it on the gateway (Add Model, Use Platform Key — a workspace budget must be set), or add your own provider API key for this provider. It is a configuration gap, returned before any upstream call, and is distinct from provider_key_missing (424) so the hint points at the right fix.

Resolution

Proceed as follows to resolve the error:

  1. Open the affected gateway's Add Model dialog and choose Use Platform Key to enable the Myra-provided model — and confirm the workspace has a budget set (a Platform-Key model meters against it).
  2. Alternatively, add your own API key for the model's provider under the gateway's provider settings.
  3. Retry the request. (If the request set a non-default x-aig-byok-alias, the gateway reports provider_key_missing instead — store the key under that alias.)

This error does not apply to a workspace on a paid self-serve plan: such a workspace routes Claude on the managed pool key automatically, with nothing to enable. If a subscription workspace cannot use a Claude model, the cause is the plan, not a missing grant — the model is outside the plan's included set (403 plan_model_not_allowed), or the plan's included set is empty, in which case chat reports that no AI provider is connected. Check the plan's models under GET /admin/v1/plan-config.

-> The request succeeds once the Platform-Key model is enabled (with a budget) or an own provider key is stored.

Error: 500 configuration_error

Description

The gateway returns HTTP 500 with code configuration_error when the gateway configuration itself cannot be loaded or parsed — for example, a malformed or incomplete gateway configuration, or a route that resolves to a disallowed/unsafe upstream. The accompanying message is Gateway configuration error. This is an administrative condition rather than something an end user can resolve. (A missing provider API key is reported separately as provider_key_missing (424), above.)

Resolution

Proceed as follows to resolve the error:

  1. Open the Request logs view and locate the failed request; note the request ID and the gateway slug.
  2. Review the affected gateway's configuration for invalid or missing settings.
  3. Contact Myra Security support with the request ID and timestamp if the cause is not apparent.

-> The gateway resumes normal operation once the configuration error is corrected.

Error: model_not_allowed_for_project

Message: This project only allows local models. Pick a local model to continue.

The gateway rejects the request when a conversation in a Local only project is sent to a cloud model. A Local only project (its Access tier) may use only local Myra models; cloud models, web search, and external tools are disabled so that data never leaves Myra infrastructure. The model picker normally hides cloud models in such a project, but the check is also enforced server-side, so an explicitly supplied cloud model is rejected.

Proceed as follows to resolve the error:

  1. Open the model picker in the composer and select a local Myra model, or select Auto to let the server choose an allowed model.
  2. If the conversation must use a cloud model, move it to a project with the User configurable or PII protection required access tier, or change the project's access tier (see Projects — Editing a project). Changing the tier requires the admin, owner, or editor role.

-> Once a local model (or Auto) is selected, the message sends normally.

Error: 403 data_residency_blocked

Message: This gateway requires EU model hosting; the selected provider/region is not EU-hosted.

The gateway rejects the request when the gateway enforces EU data residency but the selected model would run on a provider or region that is not EU-hosted. The residency floor is enforced server-side, so the request is blocked before any data leaves the EU.

Proceed as follows to resolve the error:

  1. Select an EU-hosted model. Route the request through a native EU provider — Myra or Mistral — or through an EU adapter: AWS Bedrock in an eu-* region, Google Vertex in a europe-* region, or an EU-region Azure OpenAI resource.
  2. If a non-EU model is required for this workload, use a gateway that does not enforce EU residency.

-> The request sends normally once an EU-hosted model is selected.

Error: 402 subscription_inactive

Message: Your subscription is inactive. Reactivate it in Billing to continue using the service.

The gateway rejects the request when the account's self-service subscription is not active — for example after a payment failed or the subscription was cancelled.

Proceed as follows to resolve the error:

  1. Open Settings → Billing & plans (user-block menu at the bottom of the left sidebar → Settings).
  2. Reactivate the subscription or update the payment method. See Signing up and billing.

-> The service resumes once the subscription is active again.

Error: 403 live_not_driver

Message: Someone else is driving this shared session. Request the turn to write.

The gateway rejects a write in a shared conversation when another participant currently holds the driver turn. In a shared session only the driver can send a message; everyone else follows along until the turn is released.

Proceed as follows to resolve the error:

  1. Wait for the current driver to release the turn, or ask them to hand it over.
  2. Request the turn to write, then send the message once you hold the driver turn.

-> The message sends once you hold the driver turn.