Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
dev:web_api:v3:syncing [2019/05/25 06:54] – [Collection/Tag Deletions and Syncing] dstillmandev:web_api:v3:syncing [2021/03/24 16:06] – [Handling save errors] dstillman
Line 219: Line 219:
  
   - Treat the error as fatal and stop the sync without updating the local library version   - Treat the error as fatal and stop the sync without updating the local library version
-  - Add the object key to a list of objects needing to be downloaded later and continue with the sync, updating the local library version at the end as if the sync had succeeded. In a future sync, add objects on this list to the set of objects returned from the ''versions'' request so that their data is requested again even if the remote version is lower than the library version specified in ''?since=''Ideally, retry these objects on a backoff schedule, since they may require either a server-side fix or a client update to save successfully. If these objects later appear as deleted, remove them from the list of objects.+  - Add the object key to a list of objects needing to be downloaded later and continue with the sync, updating the local library version at the end as if the sync had succeeded. In a future sync, add objects on this list to the set of objects returned from the ''versions'' request so that their data is requested again even if the remote version is lower than the library version specified in ''?since=''Retry these objects on a backoff schedule, since they may require either a server-side fix or a client update to save successfully. Skip objects in this list when uploading locally changed objects, since they are known to be out of date and would result in 412 errors. If these objects later appear as remotely deleted, remove them from the list of objects.
  
 When processing a set of objects, it may be helpful to maintain a process queue for the sync run and move failing objects to the end of the queue in case they depend on other objects being retrieved. (In many cases, it's possible to sort objects beforehand to avoid such errors, such as by sorting parent collections before subcollections.) If a loop of the process queue completes without any objects being successfully processed, stop the sync. When processing a set of objects, it may be helpful to maintain a process queue for the sync run and move failing objects to the end of the queue in case they depend on other objects being retrieved. (In many cases, it's possible to sort objects beforehand to avoid such errors, such as by sorting parent collections before subcollections.) If a loop of the process queue completes without any objects being successfully processed, stop the sync.
dev/web_api/v3/syncing.txt · Last modified: 2022/08/14 05:34 by dstillman