upgrade_tests.py 29 spurious failure while testing 1.7.17

Sigh. Once more I had a non-reproducible test failure while testing
1.7.17. It happened while running the testsuite over ra_svn + FSFS
(over ra_local there was no problem).

[[[
CMD: svnadmin.exe create svn-test-work\repositories\upgrade_tests-29
--bdb-txn-nosync --fs-type=fsfs
<TIME = 0.110000>
CMD: svnadmin.exe dump svn-test-work\local_tmp\repos | svnadmin.exe
load svn-test-work\repositories\upgrade_tests-29 --ignore-uuid
<TIME = 0.016000>
CMD: svn.exe upgrade svn-test-work\working_copies\upgrade_tests-29
--config-dir R:\test\subversion\tests\cmdline\svn-test-work\local_tmp\config
--password rayjandom --no-auth-cache --username jrandom
<TIME = 1.937000>
Upgraded 'svn-test-work\working_copies\upgrade_tests-29'
Upgraded 'svn-test-work\working_copies\upgrade_tests-29\A'
Upgraded 'svn-test-work\working_copies\upgrade_tests-29\A\B'
Skipped 'svn-test-work\working_copies\upgrade_tests-29\A\B\E'
Upgraded 'svn-test-work\working_copies\upgrade_tests-29\A\B\F'
Upgraded 'svn-test-work\working_copies\upgrade_tests-29\A\C'
Upgraded 'svn-test-work\working_copies\upgrade_tests-29\A\D'
Upgraded 'svn-test-work\working_copies\upgrade_tests-29\A\D\G'
Upgraded 'svn-test-work\working_copies\upgrade_tests-29\A\D\H'
CMD: svnadmin.exe setuuid svn-test-work\repositories\upgrade_tests-29
d7130b12-92f6-45c9-9217-b9f0472c3fab
<TIME = 0.078000>
CMD: svn.exe relocate file:///tmp/repo
svn://localhost/svn-test-work/repositories/upgrade_tests-29
svn-test-work\working_copies\upgrade_tests-29 --config-dir
R:\test\subversion\tests\cmdline\svn-test-work\local_tmp\config
--password rayjandom --no-auth-cache --username jrandom
<TIME = 0.110000>
CMD: svn.exe up svn-test-work\working_copies\upgrade_tests-29
--config-dir R:\test\subversion\tests\cmdline\svn-test-work\local_tmp\config
--password rayjandom --no-auth-cache --username jrandom
CMD: R:\test\subversion\svn\svn.exe up
svn-test-work\working_copies\upgrade_tests-29 --config-dir
R:\test\subversion\tests\cmdline\svn-test-work\local_tmp\config
--password rayjandom --no-auth-cache --username jrandom exited with 1
<TIME = 0.125000>
Updating 'svn-test-work\working_copies\upgrade_tests-29':
Restored 'svn-test-work\working_copies\upgrade_tests-29\A\B\E'
svn: E160004: Corrupt node-revision '0.0.r1/4198'
svn: E160004: Missing id field in node-rev
Traceback (most recent call last):
  File "C:\research\svn\client_build\subversion-1.7.17\subversion\tests\cmdline\svntest\main.py",
line 1319, in run
    rc = self.pred.run(sandbox)
  File "C:\research\svn\client_build\subversion-1.7.17\subversion\tests\cmdline\svntest\testcase.py",
line 176, in run
    return self.func(sandbox)
  File "C:\research\svn\client_build\subversion-1.7.17\subversion\tests\cmdline\upgrade_tests.py",
line 1228, in upgrade_missing_replaced
    None, expected_status)
  File "C:\research\svn\client_build\subversion-1.7.17\subversion\tests\cmdline\svntest\actions.py",
line 844, in run_and_verify_update
    *args)
  File "C:\research\svn\client_build\subversion-1.7.17\subversion\tests\cmdline\svntest\main.py",
line 601, in run_svn
    *(_with_auth(_with_config_dir(varargs))))
  File "C:\research\svn\client_build\subversion-1.7.17\subversion\tests\cmdline\svntest\main.py",
line 350, in run_command
    None, *varargs)
  File "C:\research\svn\client_build\subversion-1.7.17\subversion\tests\cmdline\svntest\main.py",
line 526, in run_command_stdin
    raise Failure
Failure
FAIL: upgrade_tests.py 29: upgrade with missing replaced dir
]]]

As always, I tested with Windows XP (it's end of life, I know ...
whatever) on a ramdisk, non-parellel.

This time I took a copy of repository and working copy before
rerunning the test :-). See attachment. Can anyone shed some light on
this?

I experimented a bit further with a copy of the repository and working
copy of this failed test:
- svnadmin verify says everything is ok.
- a new svn checkout over svn:// works fine.
- executing the failing "svn up" command (the last command of the
failure output) on that particular working copy, talking with that
particular repository over svn:// ... no problem.

So I'm at a loss here. I don't see any corruption, yet the test reported it.

Perhaps some kind of cache corruption is a possibility? A theory would
be nice ... anything really.

-- 
Johan