Description

It took me a while to figure out why Sentry events on my Windows builds seemed really delayed. It turns out that sentry_flush with WinHTTP does significantly more than this says:

/**
 * Instructs the transport to flush its send queue.
 *
 * The `timeout` parameter is in milliseconds.
 *
 * Returns 0 on success, or a non-zero return value in case the timeout is hit.
 */
SENTRY_API int sentry_flush(uint64_t timeout);

The first call to sentry_flush actually kills the background submission worker as well, so any envelopes created after the first flush will not be sent until the application is started a second time.

The problem seems to be a copy-paste-o, and this would fix it:

diff --git a/src/transports/sentry_transport_winhttp.c b/src/transports/sentry_transport_winhttp.c
index ef9e74b..9d509f2 100644
--- a/src/transports/sentry_transport_winhttp.c
+++ b/src/transports/sentry_transport_winhttp.c
@@ -111,7 +111,7 @@ static int
 sentry__winhttp_transport_flush(uint64_t timeout, void *transport_state)
 {
     sentry_bgworker_t *bgworker = (sentry_bgworker_t *)transport_state;
-    return sentry__bgworker_shutdown(bgworker, timeout);
+    return sentry__bgworker_flush(bgworker, timeout);
 }

 static int

When does the problem happen

• During build
• During run-time
• When capturing a hard crash

Environment

• OS: Windows 10
• Compiler: MSVC 2019
• CMake version and config: winhttp backend

Steps To Reproduce

Send a sentry event, trigger a flush, try to send a second event. The second event will not arrive until the application restarts and the background worker is re-created.

Log output

<first sentry_flush call>
[39504] flushing transport
[39504] shutting down background worker thread
[39504] submitting task to background worker thread
[39504] executing task on worker thread
[39504] background worker thread shut down
<later, when trying to flush again>
[39504] flushing transport
[39504] trying to shut down non-running thread