Skip to content

fix: null-safe getTime() calls in replication services (#3519) #3974

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
deepshekhardas wants to merge 1 commit into from
+5 −5
Closed

fix: null-safe getTime() calls in replication services (#3519) #3974

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions apps/webapp/app/services/runsReplicationService.server.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1080,8 +1080,8 @@ export class RunsReplicationService {
organizationId, // organization_id
run.projectId, // project_id
run.id, // run_id
run.updatedAt.getTime(), // updated_at
run.createdAt.getTime(), // created_at
run.updatedAt?.getTime() ?? Date.now(), // updated_at
run.createdAt?.getTime() ?? Date.now(), // created_at
Comment on lines +1083 to +1084

@devin-ai-integration devin-ai-integration Bot Jun 17, 2026

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.

🚩 Date.now() fallback for created_at could produce non-deduplicatable rows in ClickHouse

The ClickHouse task_runs_v2 table uses created_at in both the sort key (ORDER BY (organization_id, project_id, environment_id, created_at, run_id)) and the partition key (PARTITION BY toYYYYMM(created_at)). ReplacingMergeTree deduplicates rows based on the sort key. If createdAt is null for a replication event and Date.now() is used as a fallback, the fabricated created_at value would differ from the real timestamp on any subsequent replication event (e.g., an update) for the same run. This means the two rows would have different sort keys and ClickHouse would not deduplicate them, even with FINAL. They could also land in different partitions. This is an inherent trade-off of the Date.now() approach — the alternative (crashing) would halt the entire replication pipeline. A possible improvement would be to skip the row entirely (similar to the !run.environmentType || !run.organizationId guard at runsReplicationService.server.ts:1032) and log a warning, rather than inserting potentially unreplaceable data. The same concern applies to sessionsReplicationService.server.ts if the sessions table has a similar schema.

Open in Devin Review

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

run.status, // status
environmentType, // environment_type
run.friendlyId, // friendly_id
Expand Down Expand Up @@ -1142,7 +1142,7 @@ export class RunsReplicationService {
// Return array matching PAYLOAD_COLUMNS order
return [
run.id, // run_id
run.createdAt.getTime(), // created_at
run.createdAt?.getTime() ?? Date.now(), // created_at
payload, // payload
];
}
Expand Down
4 changes: 2 additions & 2 deletions apps/webapp/app/services/sessionsReplicationService.server.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -800,8 +800,8 @@ function toSessionInsertArray(
session.closedAt ? session.closedAt.getTime() : null,
session.closedReason ?? "",
session.expiresAt ? session.expiresAt.getTime() : null,
session.createdAt.getTime(),
session.updatedAt.getTime(),
session.createdAt?.getTime() ?? Date.now(),
session.updatedAt?.getTime() ?? Date.now(),
version.toString(),
isDeleted ? 1 : 0,
];
Expand Down