Attachments still stored for documents rejected by sync function #1728
Comments
adamcfraser
added a commit
that referenced
this issue
Jun 22, 2016
Previously attachments that were sent inline would be persisted to the DB even if the owning document failed sync function validation. Inline attachment data in the document needs to be removed and replaced with digest references before the revision ID is calculated (since it's a change to the document body), so it's not possible to just move the entire storeAttachments processing after Sync Function execution. The fix is to split the functionality - the updateDoc callback now updates the attachments to digest in the doc body, then returns any attachment bodies for later storage. After the document passes Sync Function validation, the attachments are stored in the DB. This doesn't change the handling for multiple invocations of updateDoc (for concurrent writes). The previous implementation already had the potential to try to store a document multiple times: if the attachment already existed, it proceeds without error. The new implementation does the same - the only difference is that the attempted attachment writes happen after Sync Function validation. There's still a corner case where: (a) Document passes Sync Function validation on first attempt (b) Attachments are written (c) Document write fails and retries (someone else has updated the doc) (d) Document fails Sync Function validation on second attempt (because oldDoc has changed) For this corner case the risk/overhead associated with the attachments written in (b) is minor. In particular, it's not possible to repeatedly trigger this scenario in the same way as the previous issue. Fixes #1728.
adamcfraser
added a commit
that referenced
this issue
Jun 22, 2016
Previously attachments that were sent inline would be persisted to the DB even if the owning document failed sync function validation. Inline attachment data in the document needs to be removed and replaced with digest references before the revision ID is calculated (since it's a change to the document body), so it's not possible to just move the entire storeAttachments processing after Sync Function execution. The fix is to split the functionality - the updateDoc callback now updates the attachments to digest in the doc body, then returns any attachment bodies for later storage. After the document passes Sync Function validation, the attachments are stored in the DB. This doesn't change the handling for multiple invocations of updateDoc (for concurrent writes). The previous implementation already had the potential to try to store a document multiple times: if the attachment already existed, it proceeds without error. The new implementation does the same - the only difference is that the attempted attachment writes happen after Sync Function validation. There's still a corner case where: (a) Document passes Sync Function validation on first attempt (b) Attachments are written (c) Document write fails and retries (someone else has updated the doc) (d) Document fails Sync Function validation on second attempt (because oldDoc has changed) For this corner case the risk/overhead associated with the attachments written in (b) is minor. In particular, it's not possible to repeatedly trigger this scenario in the same way as the previous issue. Fixes #1728.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If a document with attachments gets rejected by the sync function, the attachments are still being stored to the bucket.
The text was updated successfully, but these errors were encountered: