You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been running into a persistent error while working on a site with a number of localized versions.
Integrity constraint violation: 1062 Duplicate entry '36695-103' for key 'craft_revisions_sourceId_num_unq_idx'
I have been investigating this over the past few days, and I believe what is happening is this:
The editor makes changes to the English version of the page, and sets it to copy to all the other English-language locales (there are about half a dozen)
They immediately switch over to make corresponding changes to a Spanish version of the same entry.
When they save the Spanish entry, the Copy-to-site queue job is still running in the background.
Both the front-end web process and the queue process try to generate a revision, and they use the same version number causing the collision.
So basically your classic race condition. Now, in theory this shouldn't happen, since Craft's Revisions service gets a mutex lock before it retrieves & increments the version number. My best guess it it has to do with the 3 second lock timeout. Like if one process gets the new version number but then takes more than 3 seconds to save the revision it would expire and the second process could end up trying to save using the same number.
I imagine one option would be to just increase that timeout (paging @brandonkelly). But short of that, I wonder if it would work to just wrap the copy to site job in a DB transaction? Is this something you have seen before? Looks like it was happening a couple years ago with the old version of SiteCopy, but not sure if it was ever solved there.
The text was updated successfully, but these errors were encountered:
Hmm yes i think this is a general error with craft when two users (or a queue job and a user) try to save the entry at the same time.
We could try to put the queue job in a transaction. That would not prevent the error but at least we could rollback and rerun the job a few seconds later.
Although if its the user that gets the error, I dont think the transaction inside the queue job would do anything to prevent it.
We have been running into a persistent error while working on a site with a number of localized versions.
I have been investigating this over the past few days, and I believe what is happening is this:
So basically your classic race condition. Now, in theory this shouldn't happen, since Craft's Revisions service gets a mutex lock before it retrieves & increments the version number. My best guess it it has to do with the 3 second lock timeout. Like if one process gets the new version number but then takes more than 3 seconds to save the revision it would expire and the second process could end up trying to save using the same number.
I imagine one option would be to just increase that timeout (paging @brandonkelly). But short of that, I wonder if it would work to just wrap the copy to site job in a DB transaction? Is this something you have seen before? Looks like it was happening a couple years ago with the old version of SiteCopy, but not sure if it was ever solved there.
The text was updated successfully, but these errors were encountered: