Database error when saving an entry while the copy-to-site job is running

[elivz]

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.

[lukasNo1]

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.