-
Notifications
You must be signed in to change notification settings - Fork 401
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.
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
Shuttle live service is throwing "unique constraint error" (not a bug, but can be improved imo) #2167
Comments
Running into this as well with latest version (v0.5.3) of shuttle. I'm not sure this is "not a bug" like the original title here says, though. Getting this on a near-identical fork of the example-app, with redis being completely flushed beforehand:
|
Interesting, I titled it "not a bug" because i observed in live shards. typically assumption i made was its possible for a message to be backfilled by workers before its being processed by live shards. when that happens it throws a unique constraint error. The above scenario telling us something else? is shuttle processing message twice? |
It appears a hub currently emits duplicate messages ~10% of the time, according to @BlinkyStitt 's work on a non-shuttle project of ours that also ingests directly from hubs. If the message hash at play here truly encompasses the entire message body, then it should be safe to change shuttle to just ignore any duplicate message hashes, I think. Will wait for someone with deeper fc/hubble knowledge to chime in, though. |
I'm experiencing the same, and it crashes my instance each time. I've added error-catching to avoid crashing, but I'm unsure how to handle the unique constraint error. Is it safe to upsert the duplicate data? Ignore? |
…2197) ## Why is this change needed? Shuttle defines the messages table with two unique constraints, one for the hash, another for the triple of hash, fid and type. Postgres does not allow multiple ON CONFLICT criteria, and ambiguous conflicts are essentially surfaced as uniqueness violation failures in spite of ON CONFLICT criteria given. This change alters the merge to instead attempt insert, doing nothing on any conflict, then resolving with an update if necessary and the original conflict resolution criteria is satisfied. Addresses Issue #2167 ## Merge Checklist _Choose all relevant options below by adding an `x` now or at any time before submitting for review_ - [x] PR title adheres to the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) standard - [x] PR has a [changeset](https://github.com/farcasterxyz/hub-monorepo/blob/main/CONTRIBUTING.md#35-adding-changesets) - [x] PR has been tagged with a change label(s) (i.e. documentation, feature, bugfix, or chore) - [x] PR includes [documentation](https://github.com/farcasterxyz/hub-monorepo/blob/main/CONTRIBUTING.md#32-writing-docs) if necessary. <!-- start pr-codex --> --- ## PR-Codex overview This PR updates the conflict resolution logic in `MessageProcessor` to fix ambiguity issues during upsert operations. ### Detailed summary - Updated conflict resolution logic to use `doNothing()` method instead of complex conditions - Improved handling of conflict criteria for upsert operations > ✨ Ask PR-Codex anything about this PR by commenting with `/codex {your question}` <!-- end pr-codex -->
Can confirm this was fixed by #2197 |
What is the bug?
Shuttle live subscription will intermittently throws unique constraint error.
since its throwing error, it can cause application to crash. ideally if we can ignore that error that would be great.
How can it be reproduced?
If same message hash is processed twice this should appear.
The text was updated successfully, but these errors were encountered: