fix(ci): retry ci pr export on lane hash mismatch from concurrent pushes#10297
Merged
davidfirst merged 7 commits intomasterfrom Apr 15, 2026
Merged
fix(ci): retry ci pr export on lane hash mismatch from concurrent pushes#10297davidfirst merged 7 commits intomasterfrom
davidfirst merged 7 commits intomasterfrom
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR aims to make bit ci pr more resilient to concurrent runs exporting the same PR lane, by retrying exports when the remote rejects a lane due to hash mismatch and by improving temporary-lane cleanup behavior.
Changes:
- Add
exportWithRetryOnLaneHashMismatch()to retry export on lane-hash-mismatch by deleting the remote lane and re-exporting (up to 3 attempts). - Track whether the temp lane was renamed to the final lane name to avoid misleading temp-lane cleanup logs after rename.
GiladShoham
approved these changes
Apr 15, 2026
davidfirst
added a commit
that referenced
this pull request
Apr 15, 2026
…ompt (#10300) Follow-up to #10297. The new \`isStaleCiRun\` helper runs \`git fetch origin\` inside the hash-mismatch retry path. In the \`bit_pr\` CircleCI job, \`origin\` is the default SSH remote and GitHub's host key isn't seeded in \`known_hosts\` for that job's shell — so the fetch hits an interactive "yes/no" host-key prompt and hangs the job until the 50-minute step timeout (seen on #10257). The \`bit_merge\` job avoids this only because it rewrites \`origin\` to an HTTPS+token URL via \`update_ssh_agent\`; \`bit_pr\` does not. \`isStaleCiRun\` was added during PR review to guard a hypothetical race: an older CI run finishing later could delete a newer run's lane and re-export stale snaps. In practice that race is unlikely, self-correcting (the next CI run on the latest commit publishes the correct lane), and only affects a PR lane — not main. Removing the guard restores the original simple retry from #10297, which is enough.
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 two
bit ci prruns race on the same PR (e.g.bit-pull-request+bit-init-and-verifyworkflows, or back-to-back commits within minutes), both can pass the pre-export "existing remote lane" check, each create a fresh-hash lane locally, and then compete on export. The loser sees:The export upload/merge phase can take 1-2 minutes, which is plenty of time for the other runner to persist its lane on the hub.
exportWithRetryOnLaneHashMismatch— on hash-mismatch the helper force-deletes the remote lane (now populated by the winning push) and re-exports. Bounded to 3 attempts. Other errors and the final attempt's error propagate unchanged.finallyblock: track whether the rename to the final lane name happened, and skip the temp-lane cleanup when it did. This removes the misleading "Failed to clean up temporary lane: … was not found" log after post-rename failures.