Skip to content

Provide ExpectedOldOID to UserRevert request for race condition protection

What does this MR do and why?

This MR aims to solve the issue #384020 (closed)

This MR implements race condition protection for the UserRevert RPC by adding ExpectedOldOID support following the same pattern established in UserDeleteBranch.

Currently when reverting commits, there is a potential race condition where the target branch could be updated by another process between the time we read its current state and when we perform the revert operation. This can lead to data loss or unexpected behavior.

Solution is to add expected_old_oid parameter to the UserRevert RPC following the same pattern established in other RPCs (UserDeleteBranch, UserMergeBranch, UserFFBranch, UserCherryPick). The implementation:

  • Automatically detects the current branch SHA before performing the revert
  • Passes this SHA as expected_old_oid to Gitaly for validation
  • Fails gracefully with a clear error if the branch has changed (race condition detected)
  • Maintains full backward compatibility

Error Handling:

  • InvalidArgument errors (invalid SHA format) → CommandError
  • Internal errors (race condition detected) → CommandError
  • All existing error handling preserved

How to set up and validate locally

  1. Normal Operation Test:

    # Create test repository and revert a commit
    # Verify normal revert operations work as expected
  2. Race Condition Test:

    # Run: bundle exec rspec spec/lib/gitlab/gitaly_client/operation_service_spec.rb -e "user_revert"
    # All 13 tests should pass, including new expected_old_oid tests
  3. Integration Test:

    • Create commits in GitLab UI
    • Revert commits via the UI
    • Verify race condition protection is active (operations include expected_old_oid)
Edited by Siddharth Asthana

Merge request reports

Loading