[OAK-3079] LastRevRecoveryAgent can update _lastRev of children but not the root

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.2, 1.3.2
• Fix Version/s: 1.2.17, 1.3.5, 1.4
• Component/s: core, mongomk
• Labels: resilience
• Epic Link: DocumentMK resilience
• Assignee: Marcel Reutegger
• Reporter: Stefan Egli
• Created: 07/Jul/15 15:01
• Updated: 19/Dec/16 21:44
• Resolved: 27/Aug/15 09:07

Description

As mentioned in OAK-2131 there can be a situation wherein the LastRevRecoveryAgent updates some nodes in the tree but not the root. This seems to happen due to OAK-2131's change in the Commit.applyToCache (where paths to update are collected via tracker.track): in that code, paths which are non-root and for which no content has changed (and mind you, a content change includes adding _deleted, which happens by default for nodes with children) are not 'tracked', ie for those the _lastRev is not update by subsequent backgroundUpdate operations - leaving them 'old/out-of-date'. This seems correct as per description/intention of OAK-2131 where the last revision can be determined via the commitRoot of the parent. But it has the effect that the LastRevRecoveryAgent then finds those intermittent nodes to be updated while as the root has already been updated (which is at first glance non-intuitive).

I'll attach a test case to reproduce this.

Perhaps this is a bug, perhaps it's ok. mreutegg wdyt?

Issue Links

• is depended upon by: OAK-3305 Self recovering instance may not see all changes
• is related to: OAK-2131 Reduce usage of _lastRev
• is related to: OAK-5337 LastRevRecoveryAgent should avoid recovering documents from its own cluster id if the instance is running