What per‑event acknowledgment does the Sentry SDK provide for batch transmissions?

Question

When the Sentry SDK sends a batch of error events over HTTP, it retries failed transmissions using exponential backoff and relies on the server‑side event ID for deduplication. However, the SDK does not expose per‑event acknowledgments, so developers cannot determine which individual events were accepted on the first attempt and which must be retried. This lack of granular feedback makes it difficult to reason about duplicate writes or to implement custom fallback logic.

What information does the Sentry SDK return to the client about the success or failure of each event in a batch transmission, and how can developers infer which events may have been duplicated when a retry occurs?

Tasadduq Burney · Answer

Per-Event Acknowledgment in Sentry SDKs
The Sentry SDK does not provide per-event acknowledgments for batch transmissions. When the SDK sends a group of events, it treats the entire HTTP request as a single unit of work. The server returns a status code for the request as a whole, rather than a granular report detailing the success or failure of individual events within that payload.

Transmission Logic and Deduplication
Because the SDK cannot determine which specific events in a batch were processed before a network failure occurred, it relies on server-side deduplication. This is the primary mechanism for handling the uncertainty of retries:

Event IDs: Each event is assigned a unique ID before transmission.
  Idempotency: If a batch is partially processed by the Sentry server but the client receives a timeout or network error, the SDK retries the entire batch.
  Server Filtering: The Sentry server recognizes the duplicate Event IDs upon the second attempt and discards them, ensuring that only one instance of the error is recorded in the dashboard.

Inferring Duplication and Failures
Developers cannot programmatically infer which specific events were duplicated via the standard SDK API. However, you can monitor the transmission health using these methods:

Transport Inspection: In environments where you can implement a custom Transport interface, you can log the HTTP response codes (e.g., 200 OK vs. 5xx errors) to see if a batch failed.
  Network Proxying: Use a tool like Charles Proxy or Fiddler to observe the outgoing JSON payloads and the corresponding server responses to verify that the server is accepting the batch.

Assumptions and Verification
This behavior is consistent across most major Sentry SDKs (JavaScript, Python, Java) that utilize asynchronous batching. To verify the specific behavior of your version, check the implementation of the Transport class in your SDK's source code to see if the sendEvent or sendBatch methods handle individual response bodies.

Missing Diagnostic: To provide a more precise answer regarding custom fallback logic, please specify which SDK language and version you are using, as some platforms offer different hooks for transport interception.

What per‑event acknowledgment does the Sentry SDK provide for batch transmissions?

1 answer

0 question comments

Per-Event Acknowledgment in Sentry SDKs

Transmission Logic and Deduplication

Inferring Duplication and Failures

Assumptions and Verification

Your perspective belongs here.