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
[agent] Bench: confirmed weekly regression in yarn-berry/rescan.
Basecc938aa6 (main, 2026-10-09) → head657fce2b (main, 2026-10-15). Same machine, interleaved pairs. Daily A/B (e76cb9b3 → 657fce2b) is +4.8% [+1.8, +10.6] ≈, so this is drift that is already on main.
scenario
pairs
base wall
head wall
Δ wall [95% CI]
Δ CPU
Δ peak RSS
requests
verdict
yarn-berry/rescan (round 1)
15+10
265.1 ms
321.4 ms
+18.5% [+12.2, +31.3]
+14.6%
+5.6%
127
regression
yarn-berry/rescan (confirm)
25+15
265.9 ms
319.1 ms
+21.4% [+13.8, +25.1]
+15.7%
+5.4%
127
regression
yarn-berry/hosted (round 1)
15
335.5 ms
349.9 ms
+6.8% [-1.6, +10.9]
+9.1%
+4.9%
127
≈
Request counts are unchanged. The 2026-10-12 daily run already saw yarn-berry/rescan +15.4% (f3c6313a..17793173), below the 20% gate at the time.
Bisect (3 builds over the 151 commits cc938aa6..17793173, 15 pairs each vs cc938aa6):
So about half lands in a43cf327..eca5d247 (19 commits). The berry candidates there are a0730bb2 (#1321, retire berry resolutions left by yarn remove) and 92e001a0 (#1323, read the berry restore registry like yarn does). The rest lands in eca5d247..17793173, where 1fb8901a (#1397, berry hosted pin beside a later registry entry) is the berry-specific candidate. Not narrowed further: the bisect budget is spent.
[agent] Triaged as priority:p1 (yarn berry, npm family; perf regression). Not a duplicate of the other open bench issues (#1570 vlt, #1473 poetry, #1606 bun): the bisect points at different berry-specific commits (#1321, #1323, #1397). No open PR addresses it. Ranked below the open correctness bugs in this tier.
[agent] Claiming this issue (with #1606; shared root cause: rescan's generic discovery/selection compares every ref against every lock entry and pin with per-pair purl canonicalization and PyPI-equivalence checks, now on the npm path too; callgrind shows the same ~150M-instruction increase in both bun-isolated and yarn-berry rescans). Branch: agent/fix-rescan-per-pair-purl-compare. Claim-ID: 2026-10-23T10:21:13Z-89c608
[agent] #1693 is ready for review. It removes the shared per-pair purl work from rescans and is 7–11% faster than main on every bun and yarn-berry bench scenario. Against the original base cc938aa6, yarn-berry/rescan is now +10.1% (was +21.4%) and bun-isolated/rescan is +14.4% (was +21.3%). I'm keeping this issue open for the rest: the bun .bun store liveness walk (#599), the extra references request a rescan now makes (#1592's withdrawn-pin sweep and the hosted redirect fetch the same uuids), and berry peak RSS +10%. Details are in the PR's 'Not fixed here' section.
[agent] #1693 is merged and covers the shared part of this regression. I've removed agent:claimed so the rest can be claimed again: the bun .bun store liveness walk (#599), the extra references request per rescan (#1592's withdrawn-pin sweep fetches the same uuids as the hosted redirect), and yarn-berry peak RSS +10%. See the 'Not fixed here' section of #1693.
[agent] Claiming this issue (with #1606; shared root cause: a hosted rescan fetches registry references twice for the same pinned uuids, once in the withdrawn-pin sweep and again in the redirect). Branch: agent/fix-rescan-duplicate-references-fetch. Claim-ID: 2026-10-23T16:21:04Z-654da2
This slice covers only the duplicate references request. The bun .bun store walk and the yarn-berry peak RSS stay open.
[agent] #1695 is merged. Hosted rescans now ask the reference endpoint about each pinned patch once instead of twice. I've removed agent:claimed so the rest can be claimed: the bun .bun store liveness walk (#599) and yarn-berry peak RSS +10%.
[agent] #1701 is ready for review. It cuts yarn-berry/rescan instructions from 1,103M to 1,073M (base cc938aa6: 1,047M) by speeding up the project-patch check (it split every yarn.lock line, twice per hosted scan) and the canonical-purl check. Against main the wall change is within noise (-3.4% [-9.5, +6.4]). Against cc938aa6 it's still +10.4% wall and +10.9% peak RSS.
What remains isn't a hotspot. Peak heap is unchanged (+0.6%) and syscalls are flat. The perf binary grew 12% (44.8 to 50.0 MB) and minor page faults per run rose about 10% (6,459 to 7,087), which matches the RSS growth. The rest of the instruction growth is spread across hash-map work from features added since the base. I'm leaving this issue open with agent:needs-human: whether to do a binary-size pass or re-baseline this bench is a maintainer call.
Activity
mikolalysenko commentedon Oct 16, 2026
[agent] Triaged as
priority:p1(yarn berry, npm family; perf regression). Not a duplicate of the other open bench issues (#1570 vlt, #1473 poetry, #1606 bun): the bisect points at different berry-specific commits (#1321, #1323, #1397). No open PR addresses it. Ranked below the open correctness bugs in this tier.Generated by Claude Code
mikolalysenko commentedon Oct 23, 2026
[agent] Claiming this issue (with #1606; shared root cause: rescan's generic discovery/selection compares every ref against every lock entry and pin with per-pair purl canonicalization and PyPI-equivalence checks, now on the npm path too; callgrind shows the same ~150M-instruction increase in both bun-isolated and yarn-berry rescans). Branch: agent/fix-rescan-per-pair-purl-compare. Claim-ID: 2026-10-23T10:21:13Z-89c608
Generated by Claude Code
mikolalysenko commentedon Oct 23, 2026
[agent] Draft PR: #1693
Generated by Claude Code
Speed up rescans of bun and yarn berry projects
Test berry selector index and PyPI spellings
Tighten rescan lookups after review
mikolalysenko commentedon Oct 23, 2026
[agent] #1693 is ready for review. It removes the shared per-pair purl work from rescans and is 7–11% faster than main on every bun and yarn-berry bench scenario. Against the original base
cc938aa6,yarn-berry/rescanis now +10.1% (was +21.4%) andbun-isolated/rescanis +14.4% (was +21.3%). I'm keeping this issue open for the rest: the bun.bunstore liveness walk (#599), the extrareferencesrequest a rescan now makes (#1592's withdrawn-pin sweep and the hosted redirect fetch the same uuids), and berry peak RSS +10%. Details are in the PR's 'Not fixed here' section.Generated by Claude Code
mikolalysenko commentedon Oct 23, 2026
[agent] #1693 is merged and covers the shared part of this regression. I've removed
agent:claimedso the rest can be claimed again: the bun.bunstore liveness walk (#599), the extrareferencesrequest per rescan (#1592's withdrawn-pin sweep fetches the same uuids as the hosted redirect), and yarn-berry peak RSS +10%. See the 'Not fixed here' section of #1693.Generated by Claude Code
mikolalysenko commentedon Oct 23, 2026
[agent] Claiming this issue (with #1606; shared root cause: a hosted rescan fetches registry references twice for the same pinned uuids, once in the withdrawn-pin sweep and again in the redirect). Branch: agent/fix-rescan-duplicate-references-fetch. Claim-ID: 2026-10-23T16:21:04Z-654da2
This slice covers only the duplicate
referencesrequest. The bun.bunstore walk and the yarn-berry peak RSS stay open.Generated by Claude Code
mikolalysenko commentedon Oct 23, 2026
[agent] Draft PR: #1695
Generated by Claude Code
Ask about each pinned patch once per rescan
mikolalysenko commentedon Oct 23, 2026
[agent] #1695 is merged. Hosted rescans now ask the reference endpoint about each pinned patch once instead of twice. I've removed
agent:claimedso the rest can be claimed: the bun.bunstore liveness walk (#599) and yarn-berry peak RSS +10%.Generated by Claude Code
mikolalysenko commentedon Oct 23, 2026
[agent] Claiming this issue (remaining slice: yarn-berry rescan wall and peak RSS). Re-measured on main
3114a28vscc938aa6, 25+10 pairs:yarn-berry/rescanwall +12.4% [+9.0, +15.3], CPU +8.8%, peak RSS +10.4%. Branch: agent/fix-yarn-berry-rescan-residual. Claim-ID: 2026-10-23T21:21:11Z-297011Generated by Claude Code
mikolalysenko commentedon Oct 23, 2026
[agent] Draft PR: #1701
Generated by Claude Code
Speed up the project-patch check on big locks
Check canonical purls a byte at a time
Guard the patch-line search against stalls
mikolalysenko commentedon Oct 23, 2026
[agent] #1701 is ready for review. It cuts
yarn-berry/rescaninstructions from 1,103M to 1,073M (basecc938aa6: 1,047M) by speeding up the project-patch check (it split every yarn.lock line, twice per hosted scan) and the canonical-purl check. Against main the wall change is within noise (-3.4% [-9.5, +6.4]). Againstcc938aa6it's still +10.4% wall and +10.9% peak RSS.What remains isn't a hotspot. Peak heap is unchanged (+0.6%) and syscalls are flat. The perf binary grew 12% (44.8 to 50.0 MB) and minor page faults per run rose about 10% (6,459 to 7,087), which matches the RSS growth. The rest of the instruction growth is spread across hash-map work from features added since the base. I'm leaving this issue open with
agent:needs-human: whether to do a binary-size pass or re-baseline this bench is a maintainer call.Generated by Claude Code