Request Queueing and Retries

The TUNE SDKs include extensive logic for request queueing and retries. This logic ensures that requests are processed once, in order, by our Measurement API, and they are retried in case the device goes offline unexpectedly.

  1. App calls SDK’s measureAction() method.
  2. SDK creates a unique transaction ID and constructs the URL.
  3. URL is enqueued and queue is saved to disk.
  4. First queued request is sent to server.
  5. Server response received:
    • HTTP 2XX?
      1. Remove request from queue.
      2. Update queue on disk.
      3. Send next item from queue.
    • HTTP 400 with an X-MAT-Responder header?
      1. Bad request, remove from queue.
      2. Update queue on disk.
    • Any other response:
      1. Leave request in queue.
      2. Update retry_attempt value.
      3. Update request’s send date with exponential backoff based on retry_attempt count.
      4. Update queue on disk.

This algorithm is represented schematically below: