fix: prevent BigInt nanosecond precision loss in OTLP timestamps#3294
fix: prevent BigInt nanosecond precision loss in OTLP timestamps#3294nielskaspers wants to merge 1 commit intotriggerdotdev:mainfrom
Conversation
…on loss Epoch milliseconds multiplied by 1,000,000 as a Number exceed Number.MAX_SAFE_INTEGER (9,007,199,254,740,991), causing IEEE 754 floating-point precision loss before the BigInt conversion. The fix converts to BigInt first, then multiplies — matching the existing correct pattern in convertDateToNanoseconds(). Fixes triggerdotdev#3292 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
|
Hi @nielskaspers, thanks for your interest in contributing! This project requires that pull request authors are vouched, and you are not in the list of vouched users. This PR will be closed automatically. See https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md for more details. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThe pull request refactors BigInt conversion order in timestamp calculations across the event repository module. In both Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Fix IEEE 754 precision loss when converting epoch milliseconds to nanoseconds by performing BigInt conversion before multiplication instead of after.
Issue
Fixes #3292
Changes
getNowInNanoseconds(): convert to BigInt before multiplying by 1,000,000calculateDurationFromStart(): same BigInt-first conversionrecordRunDebugLog(): same BigInt-first conversionAll three fixes now match the existing correct pattern in
convertDateToNanoseconds()(line 54 ofcommon.server.ts).Testing
BigInt(ms) * BigInt(1_000_000)instead ofBigInt(ms * 1_000_000)Number.MAX_SAFE_INTEGER; eliminates ~256ns errors for the ~0.2% of cases where float multiplication exceeded safe integer range