Repository navigation
bug(ingest): event parser rejects numeric timestamps — real JS/Python Sentry SDK events are silently dropped #309
Description
What
The envelope event parser requires timestamp as an RFC3339 string. Official Sentry SDKs (JavaScript, Python) send epoch numbers (e.g. "timestamp": 1756278600.5). Such events are dropped with only a server-side warning — the SDK receives 200 OK, so the loss is invisible to users.
Meanwhile the transaction parser is the opposite: it requires timestamp as f64 and rejects RFC3339 strings.
Evidence (2026-08-27, manual envelopes against develop @ f932d7d)
WARN dropping event: deserialize failed item="event"
error=invalid type: integer `1756278600`, expected a string
WARN dropping transaction: deserialize failed item="transaction"
error=invalid type: string "2026-08-27T07:52:30Z", expected f64
Why it matters
- This is exactly the class of failure test: Verify Sentry SDK compatibility (JS + Python real-world validation) #299 (Sentry SDK compatibility validation) is meant to catch. Earlier integration testing (4d: Integration testing — Sentry SDK → TrapFall end-to-end #251) likely passed because the Rust sentry crate serializes timestamps as strings.
- Silent event loss = the product fails at its one job.
Suggested fix
Custom deserializer (or untagged enum) accepting both epoch numbers (secs, incl. float) and RFC3339 strings, normalized at parse time — for both events and transactions. Add regression tests with payloads captured from real @sentry/node and sentry-sdk Python.
Activity
ajianaz commentedon Sep 23, 2026
New evidence from the gatehouse integration (codecoradev/gatehouse#70, merged 2026-09-22,
@sentry/bunbridge → trapfall.ajianaz.dev): the merged bridge E2E test builds its event payload without atimestampfield, so this gap was never exercised by the integration validation. Any realcaptureExceptionfrom a JS-family SDK carries an epoch-numerictimestamp— meaning real production events will be silently dropped (200 OK) even with the auth/DSN bridges in place. Requesting re-triage: this is the blocking interop bug for the gatehouse→trapfall integration, ahead of #327/#328.ajianaz commentedon Oct 7, 2026
Reopened: #344 fixed numeric timestamps for Event and Breadcrumb only. The Transaction parser still rejects RFC3339 string timestamps (and likely numeric start_timestamp/timestamp from JS SDKs), so transaction events from real SDKs can still be dropped. It was auto-closed by a 'Fixes #309' line in the squashed commit message. Remaining: Transaction timestamp handling plus a real-SDK end-to-end check (#299).