HTTPError: 412 Client Error: Item has been modified since specified version

[Monika Renate Barget]

Running some pyzotero scripts to modify tags, I am running into recurring HTTP 412 errors in larger libraries:

PreConditionFailed: 
Code: 412
URL: https://api.zotero.org/groups/2287217/items/AH86TACR
Method: PATCH
Response: Item has been modified since specified version (expected 4930, found 4931)

At first, I followed recommendations in this group and deleted the item from the library,
but the error recurred naming a different item.

I have turned outsync OFF in the standalone and removed other users from the group.

Thanks for your help.

[Monika Renate Barget]

I can specify the issue further: the problem occurs when I am running scripts that add several new tags to these affected items. After the first new item, the "version" in the item is not update, so this causes the gap between "found" and "expected". I have now idea why the "version" isn't automatically set right. The issue does not seem consistent as other items with multipe new tags in the same script update the version after each turn.

[Dan Stillman]

On 2/7/20 10:42 AM, Monika Renate Barget wrote:
> I can specify the issue further: the problem occurs when I am running
> scripts that add several new tags to these affected items. After the
> first new item, the "version" in the item is not update, so this
> causes the gap between "found" and "expected". I have now idea why the
> "version" isn't automatically set right. The issue does not seem
> consistent as other items with multipe new tags in the same script
> update the version after each turn.

Can you provide an example script that triggers this?

I don't know if pyzotero has a debug mode, but you would ideally want to
examine the raw HTTP requests and responses to determine whether this is
a bug in your script, Pyzotero, or the API.

[Monika Renate Barget]

Dear Dan, I have just found a really simple fix:
I inserted time.sleep(3) after the operation that adds the new tags to allow for longer response time.
The script in question has now been running on a library of nearly 10000 items for over 10 minutes without interruption.
I am tracking the versions of the items updated by the script, and the versioning is perfect now.

Thanks for looking into this, Monika

On Friday, 7 February 2020 14:41:13 UTC+1, Monika Renate Barget wrote:

[Dan Stillman]

On 2/7/20 11:36 AM, Monika Renate Barget wrote:
> Dear Dan, I have just found a really simple fix:
> I inserted time.sleep(3) after the operation that adds the new tags to
> allow for longer response time.
> The script in question has now been running on a library of nearly
> 10000 items for over 10 minutes without interruption.
> I am tracking the versions of the items updated by the script, and the
> versioning is perfect now.

OK, but there's still some sort of bug somewhere — a delay shouldn't
affect item versioning — so we'd still want a script that triggered this
or (ideally) an HTTP log.

[Dan Stillman]

Looking at the script you posted to the forums [1], I think I know
what's happening here.

I'm not sure if we've exactly documented this anywhere, but Zotero API
requests currently aren't guaranteed to be read-after-write consistent,
meaning that the data obtained from a read immediately (up to a fraction
of a second) after a write may not reflect the new data. (This isn't
specific to version numbering — you're just getting an older copy of the
item, without the tag you just added. The version number is protecting
you from overwriting the previous change.)

The usual pattern is to use the data returned by the write request for
the next request, such that a 412 is guaranteed to mean that someone
else modified the item elsewhere. In your case, since you're getting the
items from tag searches (GET requests), that's not really an option, so
adding a delay after the previous write is one workaround. But a
better/faster approach, though a bit more complicated to code, would be
to do all the searches first, deduplicate the items, and then use a
single write request for each item that adds multiple tags, without
needing a delay afterward.


[1] https://forums.zotero.org/discussion/comment/348274/#Comment_348274