Fix USS commit data's server ID not updated
We've recently received reports of DCHECK failures reflecting an inconsistent state in the processor's tracker. The problematic scenario is as follows: 1. There's a pending local creation, which starts with a temporary server ID. At the processor/tracker level, this means an empty ID. 2. A remote deletion is received for the same entity (same client tag hash), which is treated as conflict. 3. The default conflict resolution will choose to "undelete" the entity, that is, the creation should prevail over the deletion. However, the temporary server ID must be overriden with the real one as provided in the remote update (deletion). Prior to this patch, ProcessorEntityTracker::RecordIgnoredUpdate() did partially handle this scenario because the server ID in |metadata_| was updated. However, the analogous ID in cached |commit_data_| also needs to be updated. The underlying issue has been around for very long but was reproduced consistently with recent ongoing experiments that exercise local deletions far more often. Bug: 896138 Change-Id: I53a4e0447d2b809c5691a739a220046c8642156a Reviewed-on: https://chromium-review.googlesource.com/c/1296169 Commit-Queue: Mikel Astiz <mastiz@chromium.org> Reviewed-by:Jan Krcal <jkrcal@chromium.org> Cr-Commit-Position: refs/heads/master@{#601891}
Showing
Please register or sign in to comment