Skip to content
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

fix: on conflict criteria is ambiguous and cannot be used for upsert #2197

Merged
merged 2 commits into from
Jul 18, 2024
Merged

fix: on conflict criteria is ambiguous and cannot be used for upsert #2197

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
00a1ccd
fix: on conflict criteria is ambiguous and cannot be used for upsert
CassOnMars Jul 17, 2024
8c0b0e6
add changeset
CassOnMars Jul 17, 2024
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
5 changes: 5 additions & 0 deletions .changeset/tidy-apricots-unite.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
---
"@farcaster/shuttle": patch
---

fix: on conflict criteria is ambiguous and cannot be used for upsert
51 changes: 29 additions & 22 deletions packages/shuttle/src/shuttle/messageProcessor.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@ export class MessageProcessor {
}

// @ts-ignore
const result = await trx
let result = await trx
.insertInto("messages")
.values({
fid: message.data.fid,
Expand All @@ -62,28 +62,35 @@ export class MessageProcessor {
...opData,
})
.returning(["id"])
.onConflict((oc) =>
oc
.columns(["hash", "fid", "type"])
Copy link
Member

@sds sds Jul 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

If I'm understanding the issue correctly, we could have probably replaced this line with .columns(["hash"]) and solved the problem, but this approach is perhaps more comprehensive (though it's impossible to have a conflict on hash-fid-type without also having a conflict on hash).

That said, I suppose it's technically the case that we allow two messages to have the same hash as long as they are of different types and/or from different FIDs.

Copy link
Member Author

Choose a reason for hiding this comment

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

the problem is that postgres seems to handle it ambiguously when there's two conflict conditions, but you cannot bifurcate or aggregate conflict handlers. seems odd since they allow where clauses in the conflict scope

// In case the signer was changed, make sure to always update it
.doUpdateSet({
signatureScheme: message.signatureScheme,
signer: message.signer,
raw: Message.encode(message).finish(),
...opData,
})
.where(({ eb, or }) =>
or([
eb("excluded.deletedAt", "is not", null).and("messages.deletedAt", "is", null),
eb("excluded.deletedAt", "is", null).and("messages.deletedAt", "is not", null),
eb("excluded.prunedAt", "is not", null).and("messages.prunedAt", "is", null),
eb("excluded.prunedAt", "is", null).and("messages.prunedAt", "is not", null),
eb("excluded.revokedAt", "is not", null).and("messages.revokedAt", "is", null),
eb("excluded.revokedAt", "is", null).and("messages.revokedAt", "is not", null),
]),
),
)
.onConflict((oc) => oc.doNothing())
.executeTakeFirst();

if (!result) {
const data = message.data;
result = await trx
.updateTable("messages")
.set({
signatureScheme: message.signatureScheme,
signer: message.signer,
raw: Message.encode(message).finish(),
...opData,
})
.returning(["id"])
.where((eb) =>
eb.and([
eb("hash", "=", message.hash),
eb("fid", "=", data.fid),
eb("type", "=", data.type),
eb.or([
eb("deletedAt", !opData.deletedAt ? "is not" : "is", null),
eb("prunedAt", !opData.prunedAt ? "is not" : "is", null),
eb("revokedAt", !opData.revokedAt ? "is not" : "is", null),
]),
]),
)
.executeTakeFirst();
}

return !!result;
}

Expand Down
Loading