Does the Sentry JavaScript SDK retain unsent events in memory after a flush timeout?

Question

When network requests fail, the Sentry JavaScript SDK buffers events in an in‑memory queue. Calling flush(timeout) returns a promise that resolves after the timeout even if some events remain unsent. The SDK documentation does not specify what happens to those remaining events—whether they are discarded, kept in memory indefinitely, or persisted to storage such as localStorage or IndexedDB. This ambiguity affects long‑running single‑page applications that may experience sustained outages.

What is the exact fate of unsent events after a flush timeout? Does the SDK provide any configuration to control retention or automatic retry? Are there version‑dependent differences in this behavior that developers should verify?

Tasadduq Burney · Answer

Event Retention Behavior
The Sentry JavaScript SDK retains unsent events in memory after a flush(timeout) call expires. The flush method is a mechanism to prioritize the delivery of the current queue before a process terminates (such as a page unload); it does not act as a "clear" or "purge" command for the internal buffer.

Likely Internal Mechanism
Based on the SDK's transport architecture, events that fail to send within the specified timeout remain in the internal memory queue. The SDK will attempt to retry these events during the next scheduled transmission cycle or when new events trigger a send. However, this retention is subject to the following constraints:

Queue Limits: To prevent memory leaks in long-running single-page applications (SPAs), the SDK enforces a maximum queue size. If the buffer reaches this limit during a sustained outage, the oldest unsent events are dropped to accommodate new data.
  Volatility: By default, this queue is strictly in-memory. If the user refreshes the page or closes the browser after a flush timeout, all unsent events are lost.

Persistence and Configuration
Standard initialization does not persist events to localStorage or IndexedDB. To change this behavior, you must explicitly configure the Offline caching transport. Without this specific integration, no automatic disk-based persistence occurs regardless of flush outcomes.

Verification Steps
To verify the retention behavior in your specific environment (assuming SDK v7+), follow these steps:

Simulate Outage: Use Browser DevTools to set the network to "Offline".
  Trigger Events: Generate several errors or messages to populate the queue.
  Execute Flush: Call Sentry.flush(100). The promise will resolve after 100ms, but the events will remain unsent.
  Restore Connectivity: Set the network back to "Online".
  Observe: Monitor the Network tab. You should see the SDK automatically attempt to send the previously buffered events.

Diagnostic Detail Needed: Are you using the standard BrowserTracing integration or a custom transport layer? Custom transports may override the default memory-retention logic.

Does the Sentry JavaScript SDK retain unsent events in memory after a flush timeout?

1 answer

Event Retention Behavior

Likely Internal Mechanism

Persistence and Configuration

Verification Steps

Your perspective belongs here.

0 question comments