Collections query returns an older set of data: Bug in script or in API?

[bjohas]

The collections query returns an older set of data.

zotero-cli collections

gives

   {
        "key": "P5GTNUN6",
        "version": 5367,
        "library": {
            "type": "group",
            "id": 2317526,
            "name": "TVETR-SSA",
            "links": {
                "alternate": {
                    "href": "https://www.zotero.org/groups/tvetr-ssa",
                    "type": "text/html"
                }
            }
        },

but

zotero-cli items

gives

      "library": {
            "type": "group",
            "id": 2317526,
            "name": "ODEN TVETR-SSA",
            "links": {
                "alternate": {
                    "href": "https://www.zotero.org/groups/oden_tvetr-ssa",
                    "type": "text/html"
                }
            }
        },

Why does the collections query result in older data?

[retorquere]

Looks like we both added a verbose flag 😄. My work has overwritten yours, sorry, you'll need to re-fetch. As far as I can tell, we don't send anything special across the line -- the logged requests should be all there's too it. I can't explain why there is this difference.

[bjohas]

Dan responded on the mailing list. The feeds are cached on the Zotero api side. Further the name changes didn't invalidate the collection feeds (but did invalidate the item feeds). This has now been fixed.

However, there were other stale parts of the feed that aren't explained by the name changes. I'll response Nd the the email now.

[retorquere]

It's detectable that this has happened by requesting the version of the whole library in the first call and ensuring that the version remains the same throughout subsequent calls, but this means doubling the number of api calls (not really a problem), it's susceptible to race conditions (it's possible that the library changes between the version check and the subsequent call), and all you can do when a version change is detected is stop and restart. Since there is no transaction mechanism, this means that in principle you can detect a version change in the middle of a multi-call write, and it could be pretty hard to recover from that. Zotero guards against this by having the user decide a merge interactively, not something we can do here.

[bjohas]

OK, sure, that's fine!

Thanks for adding the vebose flag as well. :)

Issue can be closed.