fix(reset): clean up lane history entries when resetting snaps#10270
Merged
davidfirst merged 6 commits intomasterfrom Apr 6, 2026
Merged
fix(reset): clean up lane history entries when resetting snaps#10270davidfirst merged 6 commits intomasterfrom
davidfirst merged 6 commits intomasterfrom
Conversation
Use the snap operation's batchId as the lane history entry key so that `bit reset` can identify and remove the corresponding entries when it deletes snapped versions. This prevents orphaned lane history entries from being exported to remotes.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes an issue where bit reset could delete snapped Version objects on a lane while leaving behind lane-history entries that still reference those removed versions, resulting in orphaned lane-history entries that can get exported and persist on remotes.
Changes:
- Allow
LaneHistory.addHistory()to accept an optionalhistoryKey, and addLaneHistory.removeHistoryEntries()to delete entries by key. - Use the snap operation
batchIdas the lane-history entry key so reset can deterministically delete the corresponding history entry. - During
reset(), collectbatchIds from removedVersionobjects and remove matching lane-history entries; update e2e coverage to verify no orphaned entries remain.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| scopes/scope/objects/models/lane-history.ts | Adds support for caller-provided history keys and removal of history entries by key. |
| components/legacy/scope/lanes/lanes.ts | Threads the optional historyKey through lane history update/save flows. |
| scopes/component/snapping/version-maker.ts | Keys lane-history “snap” entries by the snap operation batchId. |
| scopes/component/snapping/reset-component.ts | Extracts batchIds from Version objects being removed so reset can clean history. |
| scopes/component/snapping/snapping.main.runtime.ts | Removes lane-history entries matching the removed versions’ batchIds during reset. |
| e2e/harmony/lanes/lane-history-diff.e2e.ts | Updates the scenario test to assert no orphaned lane-history entry remains after reset. |
GiladShoham
approved these changes
Apr 6, 2026
| const versionObjects = await Promise.all( | ||
| versionsToRemoveStr.map((ver) => component.loadVersion(ver, consumer.scope.objects, false)) | ||
| ); | ||
| batchIds = [...new Set(compact(compact(versionObjects).map((v) => v.batchId)))]; |
There was a problem hiding this comment.
batchIds extraction uses nested compact(compact(...)) plus new Set(...), which is redundant and makes the intent harder to read. Consider simplifying to a single compact pass for missing version objects and using uniq (or a single Set) consistently for de-duping.
Suggested change
| batchIds = [...new Set(compact(compact(versionObjects).map((v) => v.batchId)))]; | |
| const loadedVersions = compact(versionObjects); | |
| batchIds = [...new Set(compact(loadedVersions.map((v) => v.batchId)))]; |
davidfirst
added a commit
that referenced
this pull request
Apr 6, 2026
…10273) Follow-up to #10270. - Replace `compact(compact(versionObjects).map(...))` with a clearer two-step: first `compact` to filter missing version objects, then `compact` on the mapped batchIds - Rewrite the e2e test doc and naming to use simple A/B/C labels instead of "local snap"/"first snap"/"final snap" — makes the snap→reset→snap flow easier to follow
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
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.
When
bit resetremoves snapped versions from a lane, the corresponding lane history entrieswere left behind — referencing version objects that no longer exist. These orphaned entries
would get exported to remotes and persist forever.
Fix: use the snap operation's
batchIdas the lane history entry key. During reset, load theversion objects being removed, collect their batchIds, and delete the matching lane history
entries before persisting.
Changes
LaneHistory.addHistory()accepts optionalhistoryKey(defaults tov4())LaneHistory.removeHistoryEntries()deletes entries by keyLanes.updateLaneHistory()/saveLane()thread the key throughVersionMaker.addLaneObject()passesbatchIdas the history keyremoveLocalVersion()extractsbatchIdsfrom versions being removedreset()removes matching lane history entries beforepersist()