#11601 Branch request can race with repo creation
Opened 10 months ago by qulogic. Modified 10 months ago

A couple days ago, I requested a repo, a branch for f38, and a branch for f37. These were all done rather close to each other as I used fbrnch to request them all at the same time.

The repo and f37 branch requests both worked fine.

However, the f38 branch request was processed too quickly. It initially complained that:

qulogic is not a maintainer of the golang-github-sigurn-crc16 package

When I re-opened the issues, it then said:

Traceback (most recent call last):
  File "/code/toddlers/plugins/scm_request_processor.py", line 200, in process
    self.process_ticket(issue)
  File "/code/toddlers/plugins/scm_request_processor.py", line 312, in process_ticket
    self.create_new_branch(issue, issue_body)
  File "/code/toddlers/plugins/scm_request_processor.py", line 825, in create_new_branch
    self.dist_git.new_branch(
  File "/code/toddlers/utils/pagure.py", line 495, in new_branch
    raise PagureError(
toddlers.exceptions.pagure_error.PagureError: Couldn't create branch in project 'rpms/golang-github-sigurn-crc16'

Request to 'https://src.fedoraproject.org/api/0/rpms/golang-github-sigurn-crc16/git/branch':
{'branch': 'f38', 'from_commit': '4911bbe9948ce92b56995f075e669d3543db0be4'}

Response:
{'error': "Remote hook declined the push: error: cannot lock ref 'refs/heads/f38': reference already exists", 'error_code': 'ENOCODE'}

Status code: 400

So either the original request worked even though I didn't have permission, or the second one did it twice?

Despite the second error, the bot then posted that the branch was created and closed the issue as fixed like normal.

  • When do you need this? (YYYY/MM/DD) N/A

  • When is this no longer needed or useful? (YYYY/MM/DD) N/A

  • If we cannot complete your request, what is the impact? Random branch creation failures.


Metadata Update from @phsmoura:
- Issue tagged with: medium-gain, medium-trouble, ops

10 months ago

Log in to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog