bug(ingest): event parser rejects numeric timestamps — real JS/Python Sentry SDK events are silently dropped

[ajianaz]

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.