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 2c7460d
Browse filesBrowse the repository at this point in the historyBrowse files
fix(u5a): handle the reserved slot rejection at creation, keep the observation on the measured token, and propagate the lock-key recheck failure
Three review rows on this pull are live against the content the branch head serves, and each
was settled by a row that fails without the change and passes with it. All four new rows were
run against the unchanged head first and failed as quoted; after the change the utils suite
and the four guardedWrite specs together print 54 test files passed, 993 tests passed and 5
skipped.
1. src/core/tools/guardedWrite.ts. The containment re-check releases the reserved chain slot
while an earlier write still holds the path, so the slot work promise was rejected before
its own chain entry could await it, and Node reports an unhandled rejection for a promise
whose first handler attaches on a later turn. The handler is attached at creation instead;
it does not consume the rejection, and the new row asserts both that nothing was reported
unhandled and that the refusal still reaches the caller. Pre-fix the row printed that the
captured list held one entry while the assertion demanded none.
2. src/core/tools/guardedWrite.ts. The durability-failure refresh fell back to a token read
taken after the lock was released, which is the read the record under the lock exists to
avoid. The refresh now reports only a token measured under the lock. Pre-fix the new row
printed that the token computation was called 2 times expected but 3 times actual.
3. src/utils/fileLock.ts. A failed lock-key re-derivation was swallowed as though it proved
the key had not moved, and the retarget path discarded its release failure. A failed
inspection now releases and propagates, and a failed release is reported with the key it
could not give up and the error itself. Pre-fix the two new rows printed that no error was
thrown where an EACCES inspection failure was demanded, and that no console report existed
where one was demanded.
Gates at this commit: prettier check exit 0 on the five touched files; eslint with
prune-suppressions and max-warnings 0 exit 0 with src/eslint-suppressions.json left byte
identical to blob f3714cd; tsc noEmit over src/tsconfig.json
exit 0. No Stryker directive, suppression entry or exclusion added.
0 commit comments