First of all, thanks for providing this package – it works great out of the box and is very easy to integrate with Neos/Flow projects.
However, I noticed a significant performance impact when Sentry/Bugsink/Glitchtip events are sent during a web request. This happens because the Sentry PHP SDK always performs a blocking HTTP call and waits for the response, even when using asynchronous HTTP clients internally. All pending promises are flushed at shutdown, so the request is effectively synchronous.
Problem
- The default Sentry PHP transport blocks the request until Glitchtip/Sentry responds.
- This can introduce 50–500 ms latency per request depending on server performance.
- Even using Guzzle’s async API does not solve the problem, because Sentry awaits all pending promises in its shutdown handler.
Proposed Solution Idea
- Introduce support for a configurable non-blocking Guzzle-based transport, which behaves like a "real" fire-and-forget HTTP sender:
- Use Guzzle’s postAsync() to start the request
- Do not wait for the promise (no wait() / no shutdown flush)
- Optionally support configurable timeouts (e.g. timeout: 0.001, connect_timeout: 0.001)
- Skip or override Sentry’s internal wait-on-shutdown behavior
This would allow Flow/Neos users to send Sentry/Glitchtip events without adding noticeable latency to page rendering, which is especially important for high-traffic or performance-sensitive applications.
Why this matters
Many Flow/Neos installations run behind reverse proxies or load balancers, where even small latency spikes accumulate quickly. A true fire-and-forget HTTP transport would provide a much faster request completion and a resilient behaviour when Glitchtip/Sentry/Bugsink is slow or unreachable
First of all, thanks for providing this package – it works great out of the box and is very easy to integrate with Neos/Flow projects.
However, I noticed a significant performance impact when Sentry/Bugsink/Glitchtip events are sent during a web request. This happens because the Sentry PHP SDK always performs a blocking HTTP call and waits for the response, even when using asynchronous HTTP clients internally. All pending promises are flushed at shutdown, so the request is effectively synchronous.
Problem
Proposed Solution Idea
This would allow Flow/Neos users to send Sentry/Glitchtip events without adding noticeable latency to page rendering, which is especially important for high-traffic or performance-sensitive applications.
Why this matters
Many Flow/Neos installations run behind reverse proxies or load balancers, where even small latency spikes accumulate quickly. A true fire-and-forget HTTP transport would provide a much faster request completion and a resilient behaviour when Glitchtip/Sentry/Bugsink is slow or unreachable