OTLP nanosecond timestamp overflow in webapp event repository

Several places in the webapp multiply epoch milliseconds by 1,000,000 before converting to BigInt, which causes IEEE 754 precision loss (~256ns errors in ~0.2% of cases). The result exceeds Number.MAX_SAFE_INTEGER (~9e15) since epoch-ms * 1e6 is ~1.7e18.

The correct pattern is BigInt(ms) * BigInt(1_000_000) (multiplication after BigInt conversion). This already exists in convertDateToNanoseconds() in the same file - the buggy functions just didn't use it.

Affected locations:

apps/webapp/app/v3/eventRepository/common.server.ts:24 - getNowInNanoseconds()

// Bug: multiplication in float-land
return BigInt(new Date().getTime() * 1_000_000);
// Fix:
return BigInt(new Date().getTime()) * BigInt(1_000_000);

apps/webapp/app/v3/eventRepository/common.server.ts:38 - calculateDurationFromStart()

// Bug:
const duration = Number(BigInt($endtime.getTime() * 1_000_000) - startTime);
// Fix:
const duration = Number(BigInt($endtime.getTime()) * BigInt(1_000_000) - startTime);

apps/webapp/app/v3/eventRepository/index.server.ts:217 - recordRunDebugLog()
apps/webapp/app/v3/runEngineHandlers.server.ts:431 - retry event recording

Impact: Low. The errors are +-256 nanoseconds, which is unlikely to cause visible issues. But it's an easy fix and prevents any edge cases with span ordering.

Context: Found during compute workload manager PR review (#3114). The supervisor's msToNano() was fixed in that PR using a split approach that also preserves sub-ms precision from performance.now() arithmetic.

Linear: TRI-8269

fix: convert to BigInt before multiplying to avoid nanosecond precisi…

fix: convert epoch-ms to BigInt before nanosecond multiplication

fix: prevent IEEE 754 precision loss in OTLP nanosecond timestamps

fix: convert to BigInt before nanosecond multiplication in all instances

fix: OTLP nanosecond timestamp overflow from IEEE 754 precision loss

I've submitted PR #3381 fixing all instances of the BigInt overflow pattern, including the one at runEngineHandlers.server.ts:432 that was missed in the previous PR #3378. However, the PR was auto-closed because I need to be vouched as a contributor. Could a maintainer please help with that?

fix: prevent nanosecond overflow in OTLP timestamps

fix(webapp): fix BigInt nanosecond precision loss in retry event star…

Hi! I've written a fix for this precision loss issue and submitted PR #4499. However, the PR was automatically closed because I am not on the vouched contributors list yet. Could a maintainer please vouch for me so I can reopen the PR? Thank you!

Hi — noticed this is still open and the buggy BigInt(ms * 1e6) pattern is still on main in eventRepository/common.server.ts. Prior spam PRs were closed; no open claim.

Happy to ship a clean TS fix: switch all ms→ns sites to BigInt(ms) * BigInt(1_000_000) (matching convertDateToNanoseconds), plus a small regression test.

If useful, could you /bounty $125 on this issue via Algora? I’ll exclusive-PR within 48–72h as @robinthedev-a11y.

Happy to adjust amount/scope. Thanks for the OSS + past Algora payouts.

Navigation Menu

Repository navigation

OTLP nanosecond timestamp overflow in webapp event repository #3292

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

OTLP nanosecond timestamp overflow in webapp event repository #3292

Description

Activity

aayushbaluni commented on Apr 15, 2026

AkhilTrivediX commented on Aug 4, 2026

robinthedev-a11y commented on Sep 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions