-
-
Notifications
You must be signed in to change notification settings - Fork 112
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
FOREIGN KEY constraint failed
errors
#489
Labels
Comments
tarsius
changed the title
Apr 25, 2022
FOREIGN KEY constraint
errorsFOREIGN KEY constraint failed
errors
This was referenced Apr 25, 2022
On second thought, I would expect |
tarsius
added
bug unconfirmed
An unconfirmed issue, might be a bug
and removed
bug
Something isn't working
labels
Sep 25, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Several issues about such errors have been opened in the past. I am now closing most that are still open and open this one to start over. Different issues can lead to this error, both known and unknown.
Known causes
FOREIGN KEY constraint failed
on Github [workaround available] #294 Should be fixable but I haven't gotten around to that yet. If you experience this error on Github, then please first activate the workaround proposed in that issue.Potential causes
Pagination
If, for example, another user creates a new issue, while we fetch issues, then it could happen that we fetch the same issue twice: We fetch the newest 100 issues, someone adds a new issue, and we fetch issue 201-300, but what was once the 100th most recent edited issue is not the 101th most recently edited issue so we fetch it again.
Currently Forge assumes that doesn't happen. And I believe that with Github's GraphQL API it does not happen. That uses "pointers" that are suppose to prevent this very issue. However Gitlab's REST API most likely does not prevent this.
Forge could check all fetched issues for duplicates before storing them in the database. That would likely be expensive. Or it could use "insert or replace" instead of "insert" (hoping that there are no other causes, where we wouldn't want to do that).
But before implementing any countermeasures, I would first like to be more confident that this really is the cause of most or all such errors (aside from the known one above).
Please use the following debugging code to investigate. The expectation is that some issues would appear more than once in the output. The duplicates might not always be direct neighbors.
Past reports emphasized the size of affected repositories. If I am right about the cause, then it isn't so much the size that matters but how much activity is taking place while we are fetching.
The text was updated successfully, but these errors were encountered: