REQUEST_ERROR

9.4.1. Redirect Structure

A Redirect provides a way for an endpoint to direct the peer to retry a request at a different URI and/or for a different Full Track Name.

Redirect {
  Connect URI Length (vi64),
  Connect URI (..),
  Track Namespace (..),
  Track Name Length (vi64),
  Track Name (..),
}

• Connect URI: The URI to connect to for the redirected request. If the length is zero, the requester SHOULD use the current session's URI. If a server receives a Redirect with a non-zero Connect URI Length it MUST close the session with a PROTOCOL_VIOLATION.

• Track Namespace and Track Name: The Track Namespace and Track Name to use for the redirected request, together referred to as the Redirect target.

  Track Name is not meaningful for namespace-scoped requests (SUBSCRIBE_NAMESPACE, PUBLISH_NAMESPACE, SUBSCRIBE_TRACKS) and MUST be empty; an endpoint that receives a non-empty Track Name in a Redirect for a namespace-scoped request MUST close the session with a PROTOCOL_VIOLATION.

9.4.2. REQUEST_ERROR Message Format

REQUEST_ERROR Message {
  Type (vi64) = 0x5,
  Length (16),
  Error Code (vi64),
  Retry Interval (vi64),
  Error Reason (Reason Phrase),
  [Redirect (Redirect),]
}

• Error Code: Identifies an integer error code for request failure.

• Retry Interval: The minimum time (in milliseconds) before the request SHOULD be sent again, plus one. If the value is 0, the request SHOULD NOT be retried.

• Error Reason: Provides a text description of the request error. See Section 8.5.

• Redirect: Present only when Error Code is REDIRECT. See Section 9.4.1.

If a request is retryable with the same parameters at a later time, the sender of REQUEST_ERROR includes a non-zero Retry Interval in the message. To minimize the risk of synchronized retry storms, the sender can apply randomization to each retry interval so that retries are spread out over time. A Retry Interval value of 1 indicates the request can be retried immediately.

The error codes used in REQUEST_ERROR are defined in Section 12.3.