github-issues-import icon indicating copy to clipboard operation
github-issues-import copied to clipboard

Getting a 422 ERROR

Open tduchateau opened this issue 11 years ago • 14 comments

When I confirm I want to continue.

ERROR: There was a problem importing the issues.
422 Unprocessable Entity
DETAILS: Validation Failed

Looking at the GitHub API, I understand that there are also some (a bit more) detailed errors but there are not displayed.

Any hint to be able to display those errors?

Thanks!

tduchateau avatar Jan 28 '14 21:01 tduchateau

Actually, I replaced the https://github.com/IQAndreas/github-issues-import/blob/master/gh-issues-import.py#L211 by:

error_message += "\nDETAILS: " + error_details['message'] + "\nERRORS: " + error_details['errors']

The errors are:

Traceback (most recent call last):
  File "D:\Dev\Workspaces\GitHub\Tools\github-issues-import\gh-issues-import.py", line 199, in send_request
    response = urllib.request.urlopen(req)
  File "D:\Dev\Outils\Python33\lib\urllib\request.py", line 160, in urlopen
    return opener.open(url, data, timeout)
  File "D:\Dev\Outils\Python33\lib\urllib\request.py", line 479, in open
    response = meth(req, response)
  File "D:\Dev\Outils\Python33\lib\urllib\request.py", line 591, in http_response
    'http', request, response, code, msg, hdrs)
  File "D:\Dev\Outils\Python33\lib\urllib\request.py", line 517, in error
    return self._call_chain(*args)
  File "D:\Dev\Outils\Python33\lib\urllib\request.py", line 451, in _call_chain
    result = func(*args)
  File "D:\Dev\Outils\Python33\lib\urllib\request.py", line 599, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 422: Unprocessable Entity

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\Dev\Workspaces\GitHub\Tools\github-issues-import\gh-issues-import.py", line 435, in <module>
    import_issues(issues)
  File "D:\Dev\Workspaces\GitHub\Tools\github-issues-import\gh-issues-import.py", line 375, in import_issues
    result_milestone = import_milestone(milestone)
  File "D:\Dev\Workspaces\GitHub\Tools\github-issues-import\gh-issues-import.py", line 259, in import_milestone
    result_milestone = send_request('target', "milestones", source)
  File "D:\Dev\Workspaces\GitHub\Tools\github-issues-import\gh-issues-import.py", line 211, in send_request
    error_message += "\nDETAILS: " + error_details['message'] + "\nERRORS: " + error_details['errors']
TypeError: Can't convert 'list' object to str implicitly

The last line is interesting. Investigating... :-)

tduchateau avatar Jan 28 '14 21:01 tduchateau

Okay! Well!

After some painful debugging (I'm new in Python), I found out that the error comes from already existing milestone in the destination repository.

tduchateau avatar Jan 28 '14 22:01 tduchateau

After some painful debugging (I'm new in Python)

Sorry to put you through that, and thanks so much for doing the debugging!

I found out that the error comes from already existing milestone in the destination repository.

I thought I had code in place to check for already existing milestones, but maybe that was just for the labels. I will fix it when I get to the office.

Thanks!

IQAndreas avatar Apr 18 '14 05:04 IQAndreas

I have been experimenting a bit, but haven't been able to reproduce this. As I suspected, there are checks in place for if the milestone already exists in the target repository, so I believe something else is causing the issue.

Looking at the GitHub API page (which you linked to), Error 422 is returned when there are invalid fields in the request. You did a good job trying to solve the problem, with one mistake:

"\nERRORS: " + error_details['errors']

You tried using the + operator on a list (known as an array in other programming languages), which is why you didn't get any usable information printed out, but instead got a second error messages.

Do you think you could try running the script again, but use the following line there instead?

error_message += "\nDETAILS: " + error_details['message'] + "\nERRORS: " + "\n".join(error_details['errors'])

I am so very sorry that it took this long until I started tackling the issue.

IQAndreas avatar Apr 27 '14 05:04 IQAndreas

I'm getting this error as well. I added the enhanced error tracking and the result is here.

copyhacker avatar Jul 25 '14 12:07 copyhacker

FWIW, that error line also blew up for me, so I added my own tracing and noticed that my error was also due to existing milestones. So I deleted all the milestones (which is a pain BTW) and got the error again, this time because a label already exists.

Skipping existing milestones and labels would be really nice. ;)

copyhacker avatar Jul 25 '14 13:07 copyhacker

I had this issue too after copying a handful of issues, milestones and labels over and then trying to run -all without deleting the milestones and labels that had already been created by the script. I was able to start from scratch and it worked fine.

gregtalarico avatar Sep 15 '14 21:09 gregtalarico

I had the same issue too when using --all argument. It seem that the problem is the existed milestones and labels. It would be nice to add skip mechanism to the code~

enginebai avatar Dec 26 '14 14:12 enginebai

I am also facing the issue. I have removed extra labels and milestones from source and destination and the import worked fine.

LalatenduMohanty avatar Aug 05 '15 10:08 LalatenduMohanty

Same for me with --all / --open arguments, and I really did not want to remove all labels and milestones from source and destination...

I added a pprint.pprint(error_details['errors']) line to dump the error (the syntax you provided did not work for me, type issues, cf err msg provided by @copyhacker ).

On one of the repos, the error details told me of a milestone that already existed. I went through the issues and found an open issue attached to a closed milestone. I removed the relation and re-ran the script : it worked. (I did not have to remove all milestones and labels from source repo even if they existed on both sides).

On the 2nd repo, the error details told me of a label that already existed. After running the script with the -i option (unit run) without removing any label, I can tell that the existing labels on issues were correctly skipped, but not the labels on PRs. I just needed to remove the labels on PRs before running the script, and to re-add the labels on PRs manually after migration.

nathG avatar Aug 13 '15 15:08 nathG

I had the issue because it would try to re-add any closed milestones. Note that get_milestones only retrieves a list of open milestones. I changed it to:

def get_milestones(which):
    milestones = []
    milestones.extend(send_request(which, "milestones?state=closed"))
    milestones.extend(send_request(which, "milestones?state=open"))
    return milestones  

schuhschuh avatar Apr 16 '16 20:04 schuhschuh

I am having the same issue. I believe it is due to a label already existing in the target repository, but with different capitalization. Removing the label from the source repository is a workaround.

Brian-Campuzano avatar Dec 17 '16 17:12 Brian-Campuzano

@schuhschuh 's suggestion helps, but I also had the same issue because I had more than 30 labels, and all items are paginated, see:

  • https://developer.github.com/v3/#pagination
  • https://developer.github.com/v3/guides/traversing-with-pagination/

Since I had less than 100 labels, replacing get_labels(which) with the following fixed the issue for me, but the script should really gather all pages, and not be limited to 30 or 100 items:

def get_labels(which):
	return send_request(which, "labels?per_page=100")

devernay avatar Feb 19 '18 14:02 devernay

I am having the same issue. I believe it is due to a label already existing in the target repository, but with different capitalization. Removing the label from the source repository is a workaround.

Same problem here. I used the --ignore-milestone option, which also worked.

mariocapellari avatar Apr 19 '20 20:04 mariocapellari