Move fcntl to 0.3.1 - #2854
Merged
Merged
Move fcntl to 0.3.1#2854
Conversation
Contributor
Hello francoisferrand,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
francoisferrand
changed the base branch from
development/9.0
to
development/9.6
September 16, 2026 17:30
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
@@ Coverage Diff @@
## development/9.6 #2854 +/- ##
===================================================
+ Coverage 76.60% 76.72% +0.12%
===================================================
Files 206 206
Lines 14450 14450
===================================================
+ Hits 11069 11087 +18
+ Misses 3371 3353 -18
Partials 10 10
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Contributor
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
delthas
approved these changes
Sep 17, 2026
DarkIsDude
approved these changes
Sep 17, 2026
francoisferrand
force-pushed
the
improvement/BB-887
branch
from
September 17, 2026 13:30
0588e24 to
68f47ac
Compare
Use the latest Node 22 compatible N-API node-fcntl tag after its smoke-test refresh. Issue: BB-887 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
francoisferrand
force-pushed
the
improvement/BB-887
branch
from
September 17, 2026 13:48
68f47ac to
57765e8
Compare
Contributor
Author
|
/approve |
Contributor
|
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
This pull request did not target the following hotfix branch(es) so they
Please check the status of the associated issue BB-887. Goodbye francoisferrand. The following options are set: approve |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
0.2.2 is stuck on NAN and pins node-gyp 8 internally, which no longer builds on recent Node. 0.3.0 is the N-API rewrite arsenal already depends on, so this aligns backbeat with what the tree resolves anyway and takes one blocker off the Node 24 upgrade.
Nothing else pinned 0.2.2 on this line, so it drops out of the lockfile along with the node-gyp 8 subtree it pulled in — hence the large but very one-sided
yarn.lockdiff (334 deletions). No package changes version and none are added; every removed entry is attributable to 0.2.2's tree.node-gyp8 is gone entirely, only the^11.1.0that 0.3.0 uses remains.The binding surface is unchanged.
index.jsis byte-identical between the two tags and still exports the sameposixFadvise(fd, offset, len, advice). Diffing the NAN and N-APIfcntl.cppgives the same signature, same return value and the same short-circuit to 0 on macOS/Windows; the only difference is the error object built on theres < 0branch, whichposix_fadvisedoesn't take since it returns the errno instead of -1. backbeat never requires fcntl directly — the only consumer is arsenal'sreleasePageCacheSync, which just checksret !== 0.Deliberately separate from the Node 24 runtime bump (BB-888): this is a NAN to N-API swap of a native module, so it should be visible on its own rather than tangled with a runtime change. Nothing here bumps Node, the Dockerfile, CI or
engines— it lands and is green on Node 22.Verified on Node 22:
yarn install --frozen-lockfileclean, native module builds and loads, realposix_fadviseexercised on linux (macOS short-circuits to 0) returning 0 for DONTNEED/WILLNEED and EBADF for a bad fd, arsenal'sreleasePageCacheSyncworks, 1984 unit tests passing, lint clean.Issue: BB-887