Share extension causing updates to be skipped?

[dstillman]

This looks a lot like the share extension is advancing the library version without actually downloading objects.

api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:08 -0500] "GET /users/xxxxxx/collections?format=versions&since=6887 HTTP/1.1" 200 2 "-" "ZShare/1.0.24 (org.zotero.ios.Zotero.ZShare; build:222; iOS 17.3.0) Alamofire/5.8.0"
api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:08 -0500] "GET /users/xxxxxx/groups?format=versions HTTP/1.1" 200 2 "-" "ZShare/1.0.24 (org.zotero.ios.Zotero.ZShare; build:222; iOS 17.3.0) Alamofire/5.8.0"
api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:16 -0500] "POST /users/xxxxxx/items/CIZHEBTQ/file HTTP/1.1" 200 12 "-" "ZShare/1.0.24 (org.zotero.ios.Zotero.ZShare; build:222; iOS 17.3.0) Alamofire/5.8.0"
api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:15 -0500] "POST /users/xxxxxx/items HTTP/1.1" 200 548 "-" "ZShare/1.0.24 (org.zotero.ios.Zotero.ZShare; build:222; iOS 17.3.0) Alamofire/5.8.0"

api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:21 -0500] "GET /users/xxxxxx/groups?format=versions HTTP/1.1" 200 2 "-" "Zotero/1.0.24 (org.zotero.ios.Zotero; build:222; iOS 17.3.0) Alamofire/5.8.0"
api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:21 -0500] "GET /users/xxxxxx/collections?format=versions&since=7195 HTTP/1.1" 200 2 "-" "Zotero/1.0.24 (org.zotero.ios.Zotero; build:222; iOS 17.3.0) Alamofire/5.8.0"
api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:21 -0500] "GET /users/xxxx/settings?since=6887 HTTP/1.1" 200 243 "-" "Zotero/1.0.24 (org.zotero.ios.Zotero; build:222; iOS 17.3.0) Alamofire/5.8.0"
api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:22 -0500] "GET /users/xxxx/items?format=versions&since=7197 HTTP/1.1" 304 - "-" "Zotero/1.0.24 (org.zotero.ios.Zotero; build:222; iOS 17.3.0) Alamofire/5.8.0"
api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:21 -0500] "GET /users/xxxx/searches?format=versions&since=6887 HTTP/1.1" 200 2 "-" "Zotero/1.0.24 (org.zotero.ios.Zotero; build:222; iOS 17.3.0) Alamofire/5.8.0"
api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:22 -0500] "GET /users/xxxx/items/trash?format=versions&since=6887 HTTP/1.1" 200 2 "-" "Zotero/1.0.24 (org.zotero.ios.Zotero; build:222; iOS 17.3.0) Alamofire/5.8.0"
api.zotero.org x.x.x.x - - [03/Mar/2024:11:59:22 -0500] "GET /users/xxxx/deleted?since=6887 HTTP/1.1" 200 317 "-" "Zotero/1.0.24 (org.zotero.ios.Zotero; build:222; iOS 17.3.0) Alamofire/5.8.0"

[dstillman]

Recent reports:

https://forums.zotero.org/discussion/112860/ios-syncing-issue
https://forums.zotero.org/discussion/112915/ios-not-syncing
https://forums.zotero.org/discussion/112952/some-items-fail-to-sync-from-computer-to-ios

[mvasilak]

Couldn't recreate such a scenario so far. During sharing, sync happens always before advancing any versions. We can ask the users to describe how they use the share extension, to understand if there is an edge case we haven't covered,

[dstillman]

And that's the case even if the app is force-quit?

[dstillman]

Did you try with 1.0.24?

[dstillman]

Oh, wait, 1.0.24 is from November, not February. Maybe this is an old bug that we fixed, and these people were using outdated versions?

[mvasilak]

And that's the case even if the app is force-quit?

It shouldn't matter, as the share extension itself will sync any changes in the local database.

[dstillman]

Well, it looks like the share extension just uploads new items without passing If-Unmodified-Since-Version (so presumably with version: 0 for each object), so it doesn't need to download items at all and can let the app do that later.

But I figured it out. It's the file upload request. When there's a file, the version number gets advanced and the app misses remote updates.

1. Force-quit the app
2. On desktop, add an item
3. On iOS, save https://arxiv.org/abs/2307.03202
4. Open app and the item from the desktop won't be present

[dstillman]

Along with fixing this, we'd ideally trigger a "full sync" on upgrade — i.e., a sync that checks the versions of all objects in the online library and compares to the local versions, and then downloads updates. (It would also look for local changes that were missing remotely, but that wouldn't matter here.) I can't remember if we ever implemented code to do that on iOS.

[mvasilak]

I found out why my first tests didn't produce the error. I saved a science direct article, which always resulted to the "ExtensionViewModel: upload authorized" case, that doesn't cause the issue.

When I saved the article you suggested @dstillman, it followed the alternate case "ExtensionViewModel: file exists remotely", that indeed saves the items version, overlooking the unfetched changes. Removing that, resolves this issue.

[dstillman]

We previously ran a full sync on startup — seemingly to fix an extremely similar bug — but it looks like that was done as a one-off. If that's still what's in place, we should instead use a counter there that we can increment when this needs to be done, and then have it run now for upgraders.

[mvasilak]

Closed by #884 & #885