Replace custom Sentry HTTP client with standard sentry SDK

[svarlamov]

Summary

Replaces the hand-rolled SentryClient (manual DSN parsing, X-Sentry-Auth header construction, raw JSON payloads via minreq) with the official sentry Rust SDK (v0.37, ureq transport).

What changed:

• Added sentry crate with backtrace, contexts, ureq, rustls features
• Replaced SentryClient struct and its from_dsn/send_event methods with sentry::Client + sentry::Hub
• Events are now constructed as proper sentry::protocol::Event structs instead of raw serde_json::Value blobs
• Extracted helpers: resolve_enterprise_dsn, resolve_oss_dsn, build_sentry_client, base_sentry_tags, context_to_extra, parse_sentry_level, parse_timestamp, send_event_to_client
• SentryClients struct holds long-lived Arc<sentry::Client> instances, created once in the flush loop and reused across all flush cycles
• Original event timestamps are preserved (RFC 3339 → SystemTime) instead of relying on SDK auto-timestamping
• Explicit sentry_clients.flush(5s) call after each batch ensures the async transport delivers events before the batch is considered complete
• PostHog integration, metrics, CAS sync, and TelemetryEnvelope IPC are unchanged

Updates since last revision

• Pre-epoch timestamp safety: parse_timestamp now guards against negative i64 values from dt.timestamp() — pre-epoch or malformed timestamps fall back to SystemTime::now() instead of panicking from unsigned wraparound.

Review & Testing Checklist for Human

• Flush timeout vs. flush interval: sentry_clients.flush(Duration::from_secs(5)) blocks the spawn_blocking task for up to 5s if the network is slow. FLUSH_INTERVAL is 3s, so a slow flush could cause batches to accumulate. Additionally, the flush() return value (bool indicating whether all events were sent) is currently ignored — if the timeout is reached, events are silently dropped with no logging. Verify this is acceptable or add a debug_log on timeout.
• Dependency footprint: The Cargo.lock gained ~1000 lines of new transitive deps including hyper, hyper-util, tokio-rustls, http, http-body, etc. Confirm this is acceptable for binary size and compile time, and that ureq transport is actually being used (not the default reqwest/curl transport pulling in hyper transitively via some other path).
• Timestamp precision: parse_timestamp uses dt.timestamp() which truncates sub-second precision from the original RFC 3339 timestamps. The old code passed the full string through to Sentry's JSON API. Verify whether sub-second precision matters for your Sentry dashboards.
• DSN changes at runtime: SentryClients is constructed once when the flush loop starts. If DSN configuration changes at runtime (e.g., config file update, env var change), the clients won't pick up the new DSNs until the daemon restarts. Confirm this matches the expected behavior.

Suggested test plan: Deploy to a test environment with valid OSS/Enterprise DSNs configured. Trigger error, performance, and message telemetry events, then verify they appear in both Sentry dashboards with correct tags, extra data, level, release version, and timestamps that match event creation time (not flush time).

Notes

• minreq is still a dependency (used by PostHog and CAS flush paths).
• The old SentryClient::send_event() was fully synchronous (blocking HTTP call per event, with status code check). The new code enqueues events via hub.capture_event() (non-blocking) then calls client.flush() once at the end of the batch — this should be more efficient when sending multiple events per cycle, but individual per-event error responses are no longer surfaced.

Link to Devin session: https://app.devin.ai/sessions/32562d5f120d422fb3a6fa92035193f1
Requested by: @svarlamov

---

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 11 additional findings in Devin Review.

[devin-ai-integration]

🟡 parse_timestamp truncates sub-second precision from event timestamps

The parse_timestamp function uses dt.timestamp() which returns only whole seconds, discarding all sub-second precision from the RFC 3339 timestamp string. The old code passed the timestamp string directly into the JSON payload (e.g., "timestamp": error.timestamp), preserving full millisecond/nanosecond precision. Now every Sentry event timestamp is rounded down to the nearest second.

Fix: include subsecond nanoseconds

Use dt.timestamp_subsec_nanos() to reconstruct a full-precision SystemTime:

Some(SystemTime::UNIX_EPOCH + std::time::Duration::new(secs as u64, dt.timestamp_subsec_nanos()))

Suggested change

	let secs = dt.timestamp();
	if secs >= 0 {
	Some(SystemTime::UNIX_EPOCH + std::time::Duration::from_secs(secs as u64))
	let secs = dt.timestamp();
	if secs >= 0 {
	Some(SystemTime::UNIX_EPOCH + std::time::Duration::new(secs as u64, dt.timestamp_subsec_nanos()))

---

Was this helpful? React with 👍 or 👎 to provide feedback.