feat(sync): add delayed task submission for throttling

[jpnurmi]

Add sentry__bgworker_submit_delayed() to allow deferring task execution by a given number of milliseconds. This paves the road for HTTP retries that should be first throttled on startup (similar to Cocoa/iOS and Java/Android SDKs that throttle HTTP retries by 100ms) and then scheduled with exponential backoff (15min, 30min, 1h, 2h, ...).

// delay 100ms
sentry__bgworker_submit_delayed(bgworker, http_retry_task, sentry_envelope_free, envelope, 100);

Required for:

• feat(transport): add HTTP retry with exponential backoff #1520

#skip-changelog (internal)

[github-actions]

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

Generated by 🚫 dangerJS against 90295b8

[jpnurmi]

@sentry 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]

@sentry review

[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]

Flush skips eligible delayed tasks

Medium Severity

bgworker_flush derives delay_ms from bgw->last_task only, so a far-future tail task forces delay_ms to 0 even when earlier delayed tasks are due within timeout. The flush sentinel is then scheduled too early via sentry__bgworker_submit_delayed, and sentry__bgworker_flush can report success before runnable delayed tasks execute.

Additional Locations (1)

• src/sentry_sync.c#L379-L381

 

[cursor]

Delayed deadline can wrap around

Low Severity

s쳻sentry__bgworker_submit_delayedcomputesexecute_afterassentry__monotonic_time() + delay_mswithout overflow handling. For very largedelay_ms`, unsigned wraparound can place the deadline in the past, causing the task to execute immediately instead of being deferred.

 

[sentry]

Bug: A race condition in sentry__bgworker_flush() can cause it to return prematurely if new tasks are submitted concurrently during the flush operation.
_{Severity: MEDIUM}

Suggested Fix

To fix this, the lock should be held for the entire duration of the operation. Specifically, the lock should be acquired before reading the last_task and only released after the flush sentinel has been successfully submitted to the task queue. This ensures that no new tasks can be inserted between calculating the sentinel's position and enqueuing it.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/sentry_sync.c#L366-L375

Potential issue: A race condition exists in the `sentry__bgworker_flush()` function. The
function calculates a delay for a flush sentinel based on the last task in the queue
while holding a lock. It then releases the lock before submitting the sentinel task. In
the time between releasing the lock and submitting the sentinel, another thread can add
a new task with a later deadline. This results in the sentinel being placed in the queue
before the newly added task, causing the `flush()` function to return prematurely before
all tasks have completed.

_{Did we get this right? 👍 / 👎 to inform future reviews.}