fix(replication): correct Postgres epoch constant (#4002)

[gtx20060124-bot]

Fixes #4002

The Postgres epoch constant was 7 days off (946080000000 vs correct 946684800000).
This affects keepalive timestamp decoding and standby status ack encoding.

Changed both occurrences to the correct value that matches pgoutput.ts.

[changeset-bot]

⚠️ No Changeset found

Latest commit: f9900fa

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

[github-actions]

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

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 1dd0fc67-536a-4f06-92c4-2e89c9f8b7fb

📥 Commits

Reviewing files that changed from the base of the PR and between 135c7e9 and f9900fa.

📒 Files selected for processing (1)

• internal-packages/replication/src/client.ts

---

Walkthrough

In LogicalReplicationClient within internal-packages/replication/src/client.ts, the millisecond epoch offset constant used to convert Date.now() into a PostgreSQL WAL timestamp is corrected from 946080000000 to 946684800000 in two places: the pgoutput keepalive handler (which computes the timestamp for emitted heartbeat events) and the acknowledge(lsn) method (which computes the now value used to derive upperTimestamp and lowerTimestamp written into the replication acknowledgement buffer). No public API signatures are changed.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🟡 Lower 32 bits of ACK timestamp computed in milliseconds instead of microseconds

The lowerTimestamp on line 663 computes the remainder of the 64-bit timestamp split in milliseconds instead of microseconds. The comment on line 660 states the timestamp should be "microseconds since midnight 2000-01-01", and the upper 32 bits are correctly derived from microseconds via now / 4294967.296 (which equals now * 1000 / 2^32). However, lowerTimestamp = Math.floor(now - upperTimestamp * 4294967.296) yields a value that is the remainder in milliseconds — it's ~1000× too small. The correct formula is Math.floor(now * 1000 - upperTimestamp * 4294967296) or equivalently Math.floor((now - upperTimestamp * 4294967.296) * 1000). You can verify by comparing the parsing logic at internal-packages/replication/src/client.ts:366 which correctly performs the inverse: upper * 4294967.296 + lower / 1000 — note the /1000 on the lower part, confirming the lower 32 bits are expected to be in microseconds. This pre-existing bug means the standby status update timestamp sent to PostgreSQL (used for pg_stat_replication.reply_time monitoring) can be off by up to ~71.6 minutes.

Suggested change

	const lowerTimestamp = Math.floor(now - upperTimestamp * 4294967.296);
	const lowerTimestamp = Math.floor((now - upperTimestamp * 4294967.296) * 1000);

---

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