bit ci pr --keep-lane: lane reuse mixes artifact generations in capsules, deterministically failing core-component specs from the second push

[zkochan]

Summary

bit ci pr --keep-lane (snapAndExportReusingLane) reuses the PR lane across pushes. Components unchanged since an earlier export keep their lane versions — with build artifacts produced from older commits of the branch. The build capsules of later runs then mix generations of @teambit runtime packages, and cross-copy class identity breaks inside capsule-run specs: instanceof checks fail when the error/class crosses two copies of the same package built from different commits.

On a PR that snaps core components — the only kind whose specs execute in bit_pr at all — this fails deterministically from the second push onward: run 1 on a fresh lane is green, every later run is red, with identical branch content.

Observed failure signature

Always the same three components (teambit.component/snapping, teambit.component/checkout, teambit.lanes/lanes), e.g.:

AssertionError: expected 'should have thrown an error' to include 'unable to set the following component…'
ComponentNotFoundInPath: error: component in path "comp1" was not found ...
MissingBitMapComponent: error: component "<hash>-remote/comp1@0.0.4" was not found on your local workspace.

Instrumented diagnosis (specs logging their own state on CI): a freshly tagged component with its directory present reported getComponentStatusById → {deleted: true}. That happens in component-status-loader.ts when a load throws ComponentNotFoundInPath / MissingBitMapComponent — and in the mixed-generation capsule the thrown error comes from one copy of the defining package while the err instanceof ... catch tests against another copy's class, so tolerant paths (checkout reset restoring deleted files, staged detection, lane remote resolution) turn into hard failures.

Evidence

Eleven bit_pr runs across two PRs/lanes during #10582 (and its predecessor #10567), with content bisection down to single variables:

• Fresh lane, any content (pure master, master+GVS-code, full branch): green, specs confirmed executing.
• Reused lane, any content (code disabled behind env flags, lockfile replaced with master's byte-minimal, engine pinned back): red, same three specs.
• The decisive pair: identical branch content green on a fresh lane (first push), red on the same lane's next push after changing only three files unrelated to the failing specs.
• Bisection trail preserved in the closed probe PR [CI probe - do not merge] baseline for core components' capsule MochaTest #10578 and the closing comment of feat(dependency-resolver): opt-in support for pnpm's global virtual store #10567.

The failure mode is maximally misleading: it mimics deterministic branch breakage, survives content bisection (every candidate "cause" dissolves), and never reproduces locally (workspace-mode test runs don't consume lane artifacts).

Workaround

Drop --keep-lane so bit_pr uses the temp-lane flow (each run snaps/builds everything from one commit). Applied to .circleci/config.yml in #10582 and verified: the same lane that failed the reusing flow went green on its next push and stayed green.

Possible directions for a real fix

• Invalidate reused lane components' artifacts when the snap set's dependency closure isn't generation-consistent (rebuild anything whose capsule would mix generations).
• Or version-stamp lane exports with the source commit and force re-snap of any component whose dependents get re-snapped.
• Independently: the cross-copy instanceof fragility (tracked separately) would defang the symptom.

🤖 Generated with Claude Code