[agent] Found by the scheduled Yarn Berry (2+) bug-hunt routine (ledger #305).
Summary
Suppose .yarnrc.yml sets compressionLevel: 0 with a trailing YAML comment, for example compressionLevel: 0 # keep yarn default. Yarn reads this as 0: yarn config get compressionLevel prints 0, and the lock's cacheKey is 10c0. socket-patch's flat-line reader takes the whole rest of the line, 0 # keep yarn default, as the value. So both vendored and hosted mode refuse the project as if it used a non-default compression level. The message contradicts itself:
vendor_yarn_berry_cache_unsupported: .yarnrc.yml sets `compressionLevel: 0 # keep yarn default`, which changes berry's cache checksums; only compressionLevel 0 (the yarn 4 default) is supported
redirect_yarn_berry_cache_unsupported: .yarnrc.yml sets `compressionLevel: 0 # keep yarn default`, …
Impact
A refusal fires on a supported configuration. vendor / scan --mode vendored / scan --mode hosted exit 1 and patch nothing for every npm purl in the project. Low severity, because it fails closed, but the only workaround is deleting the comment.
Repro (Linux, yarn 4.12.0 and 4.18.1)
echo '{"name":"app","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > package.json
printf 'nodeLinker: node-modules\nenableGlobalCache: false\ncompressionLevel: 0 # keep yarn default\n' > .yarnrc.yml
touch yarn.lock && yarn install
yarn config get compressionLevel # -> 0
grep cacheKey yarn.lock # -> cacheKey: 10c0
# stage .socket/manifest.json + blob for pkg:npm/left-pad@1.3.0
socket-patch vendor --json --offline # -> exit 1, vendor_yarn_berry_cache_unsupported
socket-patch scan --mode hosted … # -> exit 1, redirect_yarn_berry_cache_unsupported (mock API)Without the comment, the same project vendors, and passes a fresh yarn install --immutable with the patched bytes.
Expected vs actual
- Expected: docs/testing/yarn-berry-compatibility.md says cacheKey
10c0 / compressionLevel: 0 is supported, and the reader's doc comment says it should read the knob "the way yarn's YAML parser" does. A YAML comment isn't part of the scalar.
- Actual: the comment is read as part of the value, and the supported config is refused.
Matrix
| OS |
yarn |
vendored |
hosted |
| Linux (sandbox) |
4.12.0 |
fails |
fails |
| Linux (sandbox) |
4.18.1 |
not run |
fails |
The parser is OS-independent. Release 4.0.0 behaves the same (vendored checked).
Suspect code
crates/socket-patch-core/src/vendor/yarn_berry_lock.rs:1307 (yarnrc_compression_level: rest.trim().trim_matches(['\'', '"']) doesn't strip a #… comment). The hosted gate shares it.
[agent] Found by the scheduled Yarn Berry (2+) bug-hunt routine (ledger #305).
Summary
Suppose
.yarnrc.ymlsetscompressionLevel: 0with a trailing YAML comment, for examplecompressionLevel: 0 # keep yarn default. Yarn reads this as0:yarn config get compressionLevelprints0, and the lock's cacheKey is10c0. socket-patch's flat-line reader takes the whole rest of the line,0 # keep yarn default, as the value. So both vendored and hosted mode refuse the project as if it used a non-default compression level. The message contradicts itself:Impact
A refusal fires on a supported configuration.
vendor/scan --mode vendored/scan --mode hostedexit 1 and patch nothing for every npm purl in the project. Low severity, because it fails closed, but the only workaround is deleting the comment.Repro (Linux, yarn 4.12.0 and 4.18.1)
Without the comment, the same project vendors, and passes a fresh
yarn install --immutablewith the patched bytes.Expected vs actual
10c0/compressionLevel: 0is supported, and the reader's doc comment says it should read the knob "the way yarn's YAML parser" does. A YAML comment isn't part of the scalar.Matrix
The parser is OS-independent. Release 4.0.0 behaves the same (vendored checked).
Suspect code
crates/socket-patch-core/src/vendor/yarn_berry_lock.rs:1307(yarnrc_compression_level:rest.trim().trim_matches(['\'', '"'])doesn't strip a#…comment). The hosted gate shares it.