feat(transport): add HTTP retry with exponential backoff

[jpnurmi]

Add HTTP retry with exponential backoff for network failures, modeled after Crashpad's upload retry behavior.

Failed envelopes are stored as <db>/cache/<ts>-<n>-<uuid>.envelope and retried on startup after a 100ms throttle, and then with exponential backoff (15min, 30min, 1h, 2h, 8h). When retries are exhausted, and offline caching is enabled, envelopes are stored as <db>/cache/<uuid>.envelope instead of being discarded.

flowchart TD
    startup --> R{retry?}
    R -->|yes| throttle
    R -->|no| C{cache?}
    throttle -. 100ms .-> resend
    resend -->|success| C
    resend -->|fail| C2[&lt;db&gt;/cache/<br/>&lt;ts&gt;-&lt;n&gt;-&lt;uuid&gt;.envelope]
    C2 --> backoff
    backoff -. 2ⁿ×15min .-> resend
    C -->|yes| CACHE[&lt;db&gt;/cache/<br/>&lt;uuid&gt;.envelope]
    C -->|no| discard

Loading

See also: https://develop.sentry.dev/sdk/expected-features/#buffer-to-disk

Depends on:

•  feat(sync): add delayed task submission for throttling #1506
• ref: parse event_id from raw envelopes #1512
• ref(transport): unify and restructure HTTP transport layer #1514

See also:

• Support Offline Caching of Envelopes #1316

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against fbbffb2

[jpnurmi]

@sentry review

[jpnurmi]

@cursor review

[jpnurmi]

@sentry review

[jpnurmi]

@cursor review

[jpnurmi]

@cursor review

[jpnurmi]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

[jpnurmi]

@cursor review

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Trigger bypasses backoff and rapidly exhausts retry attempts

Medium Severity

retry_trigger_task passes UINT64_MAX as before, bypassing all backoff checks. On network failure, it immediately re-submits itself via sentry__retry_trigger. Since sentry__retry_send breaks after the first failure and bumps that file's count, and the trigger immediately re-queues, all retry attempts for every pending envelope can be exhausted in rapid succession (milliseconds) rather than over the intended hours of exponential backoff. A single mistimed call to sentry_transport_retry while offline permanently burns through all retries, causing data loss.

 

[cursor]

can_retry returns true even when retry disabled

Low Severity

sentry__transport_can_retry checks for the presence of retry_func, which is unconditionally set for all HTTP transports in sentry__http_transport_new. This means it returns true even when http_retry is false. In sentry_core.c, this causes sentry__cleanup_cache to run unnecessarily for every HTTP transport regardless of the retry option. While currently harmless (cleanup is a no-op with default cache limits), the function's semantics are misleading and could cause subtle issues if future code relies on it to indicate actual retry capability.

Additional Locations (2)

• src/transports/sentry_http_transport.c#L396-L397
• src/sentry_core.c#L292-L296