Thanks to visit codestin.com
Credit goes to github.com

Skip to content

NIFI-15657 - Fix 409 Conflict in Azure DevOps and Bitbucket Cloud when multiple flows share the same branch#10948

Open
pvillard31 wants to merge 1 commit intoapache:mainfrom
pvillard31:NIFI-15657
Open

NIFI-15657 - Fix 409 Conflict in Azure DevOps and Bitbucket Cloud when multiple flows share the same branch#10948
pvillard31 wants to merge 1 commit intoapache:mainfrom
pvillard31:NIFI-15657

Conversation

@pvillard31
Copy link
Contributor

Summary

NIFI-15657 - Fix 409 Conflict in Azure DevOps and Bitbucket Cloud when multiple flows share the same branch

  • Azure DevOps and Bitbucket Cloud flow registry clients now correctly use the branch HEAD (instead of a file-level commit SHA) for their push APIs' optimistic locking parameters, fixing 409 Conflict errors in monorepo scenarios where multiple independent flows are versioned on the same branch.
  • Both providers now implement a retry-with-file-verification loop: on 409, re-verify the target file hasn't changed, re-fetch the branch HEAD, and retry (up to 3 attempts). File-level conflicts still fail immediately.
  • Extracted fetchBranchHead() helper in AzureDevOpsRepositoryClient (also deduplicates deleteContent()), and added getBranchHeadCloud() in BitbucketRepositoryClient using the Refs API.

Root Cause

The Azure DevOps Push API requires oldObjectId to be the current branch HEAD, and the Bitbucket Cloud Source API requires parents to be the branch HEAD. Both providers were incorrectly passing the file-level commit SHA (expectedCommitSha from GitCreateContentRequest), which only equals the branch HEAD in single-flow-per-branch setups. In monorepo scenarios, any commit to a different flow file advances the branch HEAD, causing the next flow's commit to fail with 409.

Note

Azure DevOps and Bitbucket Cloud only offer branch-level optimistic locking in their push APIs, so our file-level conflict check happens client-side one HTTP round-trip before the push, leaving a narrow TOCTOU window. In practice the risk is negligible — the gap is milliseconds, and two users would have to save the exact same flow file within that window. GitHub, GitLab, and Bitbucket DC have no such gap because their APIs provide server-side file-level atomicity.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

Pull Request Tracking

  • Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
  • Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
  • Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

  • Pull Request based on current revision of the main branch
  • Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

  • Build completed using ./mvnw clean install -P contrib-check
    • JDK 21
    • JDK 25

Licensing

  • New dependencies are compatible with the Apache License 2.0 according to the License Policy
  • New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

  • Documentation formatting appears as expected in rendered files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant