To better explain the bug I'll describe the content of the revisions:
- Valid Revision
Adds child nodes a, b, c, d, e, f with various properties (blobs included)
- Invalid Revision
Adds child node z with some blob properties and then corrupts the NODE record holding z.
Now when the consistency check is run, it correctly detects that the second revision is broken, marks the path /z as corrupt and then continues checking the first valid revision. Because of a check introduced for
OAK-5556, which tries to validate the user provided absolute paths before checking them, the checker tries to check /z in the first revision, where of course it can't find it. Therefore the check incorrectly fails for this revision, although it shouldn't have to.