Skip to main content
Most Sync Server incidents are one of four shapes. Work them in this order — each rules out the layer below it.

​
1. Is the order actually stuck?

An order sitting in-flight is not necessarily failing. If its connector uses the default no_retry_after_ambiguous (dedupPolicy), an ambiguous submission parks for review rather than retrying — by design.
Do not resubmit a parked order until you have checked the partner for it. The policy parked it precisely because the platform could not tell whether the remote accepted it — resubmitting on the assumption that it did not is how a parked order becomes a duplicate shipment.

​
2. Is a circuit breaker open?

The breaker opens after 10 consecutive failures to an upstream and stays open for 30 seconds, then admits a test request. A request failing with “circuit breaker is open” is the platform protecting the upstream, not a bug in your call.
An open breaker means the upstream failed ten times in a row — so the fix is almost never at your end. Check the partner’s status before changing anything on yours. Breakers reset on restart, but restarting to clear one hides the outage that opened it.

​
3. Is it the upstream’s limits?

​
4. Is it local — the database or the process?

​
Errors you should not retry

The status-code mapping is the retry policy. Two are worth repeating here:
  • FAILED_PRECONDITION — the tenant has no configuration for that integration. Retrying forever will never fix it, and it almost always means onboarding was left incomplete. Alert on it rather than burying it in a queue.
  • DEADLINE_EXCEEDED — does not tell you whether downstream systems accepted the order. Retry per target with the single-target RPCs, never by resubmitting the whole call.

​
Next steps

Connectors

dedupPolicy, and why a parked order is the safe outcome.

gRPC flow

The full status-code mapping and per-target retry.

API contract

Envelopes and correlation ids — keep the requestId.

API basics

Authentication and tenancy.