v5.18.1 - #400
Merged
Merged
Conversation
branch-diff matches commits rather than content, so it reports commits whose
changes are already on v5.x. Two thirds of its output for v5.18.0 was noise.
The skill previously said only "skip commits that would result in empty
cherry-picks", which gives no way to tell those apart from real ones.
Document the three classes actually observed:
a. Commits subsumed by the squash-merged 5.14.2/5.14.3/5.14.4 releases.
Enumerated per release; a closed set that will not grow.
b. Dependabot bumps superseded by a later bump of the same package on v5.x.
Cherry-picking one downgrades the branch.
c. #154, the 6.0.0-pre bump on main, which must never reach a 5.x branch.
Applying these to `branch-diff v5.x main` yields exactly the 13 commits in the
v5.18.0 proposal.
Also add a `git diff --stat main` check before the version bump. An age-based
cutoff had dismissed #352 as a false positive when it was real and unapplied;
the content diff is what exposed it, so the skill now states that age alone is
not evidence and cites #352 as the counterexample.
Smaller fixes for things that misled during v5.18.0: pull both branches before
comparing, parse PR numbers from the trailing URL rather than the "(#NNN)" form
(which false-matches PR references in commit titles), clear the previous
release's worktree, and keep the version commit last on the branch.
* fix(otel-thread-ctx): feature-detect AsyncContextFrame
The writer inferred whether AsyncContextFrame was available from the Node
version plus `process.execArgv`, and threw from `enter()` when it concluded it
was not. That inference is wrong in both directions, and each way is reachable
with a flag Node itself accepts:
# Node 22.23.2 — ACF on, execArgv empty: inference says "unavailable"
$ NODE_OPTIONS=--experimental-async-context-frame node probe.js
{"isACFActive":true,"execArgv":[]}
# Node 24.18.0 — ACF off, execArgv empty: inference says "available"
$ NODE_OPTIONS=--no-async-context-frame node probe.js
{"isACFActive":false,"execArgv":[]}
Node 22 and 23 accept --experimental-async-context-frame in NODE_OPTIONS (Node
24 rejects it, and does not need it); Node 24 accepts --no-async-context-frame
there (Node 22 has no such flag). Neither reaches execArgv. A worker thread
created with an explicit execArgv doesn't inherit the main thread's command line
either, and tooling sometimes rewrites process.execArgv outright.
The false-negative makes the writer refuse to run in a process where it would
have worked. The false-positive is worse and silent: the CPED slot the addon
reads is only written when ACF is on, so the writer installs its hook, keeps
looking healthy from JS — getStore() still works — and every out-of-process
reader sees a record that nothing ever updates.
Ask the question directly instead: with ACF, AsyncLocalStorage#run is
implemented in terms of #enterWith, and without it, it isn't. The version and
execArgv are still used, but only to word the error message.
Five test-side copies of the same inference decided whether to exercise the CPED
paths, so they mis-skipped in exactly the same processes; they now share the one
detection. Their >=22.7.0 floor for time-profiler CPED support is unchanged.
* test(docker): stage the tree without tsconfig.tsbuildinfo
The runner deletes the host's node_modules, build and out before building
inside the container, but copies in tsconfig.tsbuildinfo, which is gitignored
and present on any host where `npm run compile` has been run. tsc then trusts
that incremental state, emits nothing for the deleted out/, and the run ends in
Error: No test files found: "out/test/test-*.js"
having tested nothing at all.
…ly (#398) * fix(otel-thread-ctx): detect AsyncContextFrame by reading CPED natively #397 replaced the execArgv inference with a feature detection, but the probe was indirect: it overrode `enterWith` on a throwaway AsyncLocalStorage and checked whether `run()` dispatched through it. That `run()` goes through the instance property is unspecified, and anything patching AsyncLocalStorage can break it — including dd-trace-js, which patches async-context machinery. The resulting false negative is the failure #397 set out to fix: `enter()` throwing inside a diagnostic-channel subscriber, in application code. Ask the question directly instead. `cpedMapContains(key, value)` reports whether the isolate's ContinuationPreservedEmbedderData binds a key to a value, so calling it from inside a `run()` with the probe storage and its own store observes the property the addon actually depends on. It is the same slot, and the same "is it a Map" question, that WallProfiler::SetContext asks before storing a context; the key is the one whose identity hash is published as otel_thread_ctx_nodejs_v1.als_identity_hash for the out-of-process reader to look up. Verified empirically that the frame is keyed by the storage instance with the store as value. Checking the key and value rather than just "CPED holds a Map" matters: CPED is a general embedder slot, so a Map another addon left there must not answer for us — that would resurrect the silent false positive, where the writer looks healthy from JS while readers see records nothing updates. * test: use the real 22.7.0 AsyncContextFrame cutoff
Bumps the minor-updates group with 4 updates: [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node), [@types/semver](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/semver), [eslint-plugin-n](https://github.com/eslint-community/eslint-plugin-n) and [mocha](https://github.com/mochajs/mocha). Updates `@types/node` from 26.1.2 to 26.2.0 - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node) Updates `@types/semver` from 7.7.1 to 7.8.0 - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/semver) Updates `eslint-plugin-n` from 18.2.2 to 18.3.0 - [Release notes](https://github.com/eslint-community/eslint-plugin-n/releases) - [Changelog](https://github.com/eslint-community/eslint-plugin-n/blob/master/CHANGELOG.md) - [Commits](eslint-community/eslint-plugin-n@v18.2.2...v18.3.0) Updates `mocha` from 11.7.6 to 11.8.0 - [Release notes](https://github.com/mochajs/mocha/releases) - [Changelog](https://github.com/mochajs/mocha/blob/v11.8.0/CHANGELOG.md) - [Commits](mochajs/mocha@v11.7.6...v11.8.0) --- updated-dependencies: - dependency-name: "@types/node" dependency-version: 26.2.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: minor-updates - dependency-name: "@types/semver" dependency-version: 7.8.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: minor-updates - dependency-name: eslint-plugin-n dependency-version: 18.3.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: minor-updates - dependency-name: mocha dependency-version: 11.8.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: minor-updates ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
szegedi
requested review from
IlyasShabi,
nsavoire and
r1viollet
as code owners
August 20, 2026 14:58
Overall package sizeSelf size: 2.53 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | pprof-format | 2.3.1 | 504.33 kB | 504.33 kB | | source-map | 0.8.0 | 185.66 kB | 185.66 kB | | node-gyp-build | 4.8.4 | 13.86 kB | 13.86 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
IlyasShabi
approved these changes
Aug 20, 2026
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
2 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.
Bug fixes
Other (build, dev)