Skip to content

fix: use BigInt arithmetic for nanosecond timestamp conversion - #5013

Closed
okxint wants to merge 1 commit into
triggerdotdev:mainfrom
okxint:fix/otlp-nanosecond-bigint-precision
Closed

okxint wants to merge 1 commit into
triggerdotdev:mainfrom
okxint:fix/otlp-nanosecond-bigint-precision

Conversation

@okxint

@okxint okxint commented Oct 9, 2026

Copy link
Copy Markdown

What

Three call sites compute nanosecond timestamps by multiplying Date.getTime() (a float) by 1_000_000 before converting to BigInt. Once the product exceeds Number.MAX_SAFE_INTEGER, IEEE 754 precision is lost silently.

The correct pattern already exists in the same file (convertDateToNanoseconds):

// before (precision loss)
BigInt(new Date().getTime() * 1_000_000)

// after (integer arithmetic)
BigInt(new Date().getTime()) * BigInt(1_000_000)

Changes

  • eventRepository/common.server.ts: getNowInNanoseconds and calculateDurationFromStart
  • eventRepository/index.server.ts: run-event startTime on the replay path
  • runEngineHandlers.server.ts: retry-event startTime in recordEvent

All four sites now match the pattern in convertDateToNanoseconds.

Multiplying Date.getTime() by 1_000_000 as a float before converting
to BigInt causes IEEE 754 precision loss once the product exceeds
Number.MAX_SAFE_INTEGER (~9007T, which ms * 1e6 hits around 2255 AD).

The correct pattern already exists in convertDateToNanoseconds():
  BigInt(date.getTime()) * BigInt(1_000_000)

Apply it consistently to the three call sites that still use the
float-multiply pattern (getNowInNanoseconds, calculateDurationFromStart,
and the runEngineHandlers retry-event recordEvent call).
@changeset-bot

changeset-bot Bot commented Oct 9, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 3827f4d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai

coderabbitai Bot commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

Review in Change Stack →

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration
  • Configuration used: Repository UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 61e985eb-6ae3-40a8-899a-d3b14b65df7c

📥 Commits

Reviewing files that changed from the base of the PR and between 8fcb035 and 3827f4d.


📒 Files selected for processing (4)
  • .server-changes/fix-otlp-nanosecond-bigint-precision.md
  • apps/webapp/app/v3/eventRepository/common.server.ts
  • apps/webapp/app/v3/eventRepository/index.server.ts
  • apps/webapp/app/v3/runEngineHandlers.server.ts

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create a new PR


  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions

github-actions Bot commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

Hi @okxint, 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.

@github-actions github-actions Bot closed this Oct 9, 2026

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 potential issue.

Devin Review

type: fix
---

Fix OTLP trace timestamps losing precision for runs after approximately 2255 AD. Timestamps are now computed with full 64-bit integer arithmetic.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 Release note understates affected runs

Nanosecond products exceed Number.MAX_SAFE_INTEGER by April 1970, not 2255. Current runs already lose precision under the old conversion, so this note misstates the fix's scope.

Devin Review


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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant