FileProviderReplicatedExtension’s modifyItem called immediately following fetchContents’ completion for updates from remote

Hi there,

The first time an item is materialized (via fetchContents), the contents are downloaded and we set the contentVersion (to a hash of the content) - no problems here. Once a content change is made remotely, we enumerateChanges and change the contentVersion to ”empty” (Data()). This triggers fetchContents to be called (where we fetch the new content). As soon as we call the completion handler for fetchContents though (now with a new contentVersion (a hash of the new content), we get a call immediately after to modifyContents, with the same contents that we just fetched. This call to modifyContent seems like a bug. how can I prevent it from being called by the system?

Thanks for the help!

  • What are the changedFields and options arguments to modifyItem?

    Feel free to file a feedback through Feedback Assistant, including a sysdiagnose and reproduction timestamp. We can see more details there to understand what is happening.

  • The only changeFields is .contents (contentModificationDate is not present unlike when the content is actually modified locally). No options values.

    My understanding is that the system expects the contentVersion to change during the enumeration update to act as a signal that new content is available and therefore fetch the content (given the item is in the working set). Are there similar expectations the system has that could be triggering this modifyItem call when it shouldn't be?

  • I have filed a feedback report as requested: FB12673356 (FileProvider's modifyItem being called immediately after fetchContent receives updated content). Thanks for the help!