ServiceUnavailable

Andromeda answers 503 with the problem type https://uri.etsi.org/ngsi-ld/errors/ServiceUnavailable and a Retry-After header. Something on the broker's side is failing for now, and the same request can work after the delay, so send it again once the delay has passed. This type is Andromeda's own. The specification binds InternalError to 500, a failure a client doesn't retry, so a retryable 503 gets a type of its own, and a client can base its retry policy on the type as well as the status. See Andromeda's own types.

When this comes back

• PostgreSQL is unreachable or the connection was lost, with Retry-After: 5.
• The connection pool has no connection free in time, with Retry-After: 1.
• A write rolled back under contention on every attempt, with Retry-After: 1.
• An asynchronous batch write finished, but its history was still being applied when your wait ran out. See Asynchronous history.
• A Snapshot still preparing held the operation up past snapshot.preparation.scoped_operation_timeout. See Snapshots.
• The first write to a new tenant was interrupted, and the tenant's setup didn't complete. See Tenants.

Store outages covers the database conditions, including why a repeated write is safe.

Example

HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 5

{
    "type": "https://uri.etsi.org/ngsi-ld/errors/ServiceUnavailable",
    "title": "Service unavailable",
    "status": 503,
    "detail": "the datastore is temporarily unavailable; retry shortly"
}