fix(resume): guard patch versions in the transaction, not in sql

Postgres defaultNow() stores microseconds while JS Dates are millisecond-truncated, so the SQL equality guard matched zero rows on freshly created resumes and every guarded agent patch failed with a permanent version conflict. The SELECT ... FOR UPDATE lock plus the in-transaction ms-precision check already provide the guarantee; drop the SQL predicate. Verified A/B against a live database.
This commit is contained in:
Amruth Pillai
2026-08-20 09:28:31 +02:00
parent 39590eaff6
commit 39f36b4ac5
+5 -6
View File
@@ -160,16 +160,15 @@ async function applyResumePatchTx(
}
patchedData = parseWritableResumeData(patchedData);
// The version guard is the ms-precision JS check above, under the SELECT ... FOR UPDATE lock.
// Never compare expectedUpdatedAt in SQL: rows stamped by Postgres now() (defaultNow() on
// insert) carry microseconds, while JS Dates are ms-truncated — SQL equality then matches
// zero rows and every guarded patch on a fresh resume reports a version conflict forever.
const [resume] = await client
.update(schema.resume)
.set({ data: patchedData })
.where(
and(
eq(schema.resume.id, input.id),
eq(schema.resume.isLocked, false),
eq(schema.resume.userId, input.userId),
...(input.expectedUpdatedAt ? [eq(schema.resume.updatedAt, input.expectedUpdatedAt)] : []),
),
and(eq(schema.resume.id, input.id), eq(schema.resume.isLocked, false), eq(schema.resume.userId, input.userId)),
)
.returning({
id: schema.resume.id,