You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit dd899d0
Browse filesBrowse the repository at this point in the historyBrowse files
fix(u5a): defer the orphan verdict, propagate lock-key inspection failures, pin created ancestors (#2359)
Five live CodeRabbit rows on head fb03ecb, each with a row that fails without
the fix:
- the failure path threw OrphanedBackupError before removing its own staging file
and staging directory, so every retry of the write left both behind; the verdict
is raised after that cleanup now.
- OrphanedBackupError blamed the backup step and called a complete copy partial,
although the same error is raised after a successful copy whenever the commit or
a directory fsync fails. The wording is phase-neutral and still names the target,
the copy, the original failure and both errnos.
- resolveLockKey answered every inspection failure with a lexical key built from
the alias: a realpath EACCES on a path that is a symlink parks the writer on a
different lock than the writer resolving the same file, and a mid-walk readlink
EIO returned the half-resolved key. Only ENOENT falls into the tolerant walk now;
readlink ends the walk only on ENOENT, ENOTDIR or EINVAL.
- the created-ancestor fsync chain stopped at the shallowest directory this write
created, so the entry that links that directory into the tree was never flushed.
The pre-existing parent is synced last, deepest-first.
- a parent this write created was never validated: expectedAncestorIdentities can
only pin directories the caller walked, so whoever moved the old parent aside
could move the new one, put a link at its old name, and the commit would land at
the moved location. Created directories are pinned at mkdir and re-checked at
both authorization sites.
Two rows were strengthened rather than added: the Windows DACL row counted two
icacls calls, which cannot distinguish restoring onto the target from restoring
onto the name the rename produced - it now orders save, rename, restore and pins
the restore's directory argument; the resetChain row awaited the first write before
resetting and passed with resetChain() as a no-op - it now holds the first write
inside its publish and races the second write against it. The notALink double in
the lock-key spec rejected with no errno, which models neither platform: it now
carries EINVAL on POSIX and ENOENT on Windows.
Measured with the pinned node v22.23.4, dir C:/work/Zoo-Code-fork/wt-r290-2359/src,
"node node_modules/vitest/vitest.mjs run --config vitest.config.ts
--no-file-parallelism <file>": safeWriteText.spec with the new rows and no
production change 6 failed | 77 passed (83), with the production change 83 passed
(83); guardedWrite.spec 66 passed (86 tests? no) 66 passed (66);
resetChain neutered (pendingChains.clear replaced by void pendingChains.clear)
with the strengthened row 1 failed | 65 passed (66), with the previous row 66
passed (66); the DACL restore block moved ahead of the commit rename 1 failed |
82 skipped (83) on "expected [ 'save', 'restore', 'rename' ] to deeply equal [
'save', 'rename', 'restore' ]". safeWriteJson.lockKey.spec 4 passed (4). Services
shard (vitest.services.config.ts --coverage) 11 failed | 1689 passed | 1 skipped
(1701), the 11 identical to the same command at the sibling unit's head 066f153
and located in services/marketplace, services/rules and
services/code-index/processors/parser, so not this delta. eslint
--max-warnings=0 on the four touched files: 0 problems, same as at head.
tsc --noEmit -p .: exit 0. prettier --check: clean.
0 commit comments