Importing a Bitbucket repository with a private issue tracker results in 500
Summary
Importing a repository from Bitbucket Cloud when the Bitbucket issue tracker is set to "private" rather than "public" or "none" results in a 500 error in GitLab in the import of issues. This means the import fails, so even though the source code is present in GitLab the merge requests and such are not.
Steps to reproduce
- In Bitbucket, create a repository and set the issue tracker to private
- Follow the instructions to import the repository in GitLab
- Wait a bit, and observe the import status API now returns failed with a message undefined method `[]'- for nil:NilClass"
Example Project
See logs below as well, as the source code of the projects imports successfully but there's no pull requests or anything.
Customer provided some examples in (GitLab internal link) their Zendesk ticket.
What is the current bug behavior?
A private issue tracker results in a 500 and missing / partial import data.
What is the expected correct behavior?
If we can't read a private issue tracker, we should skip issues rather than 500 and failure to import everything else.
Relevant logs and/or screenshots
Relevant pieces from (GitLab internal link) kibana Sidekiq log for customer's project:
{
"json.extra.sidekiq.class": [
"RepositoryImportWorker"
],
"json.extra.sidekiq.meta.root_caller_id": [
"Import::BitbucketController#create"
],
"json.exception.class": [
"NoMethodError"
],
"json.severity.keyword": [
"ERROR"
],
"json.extra.project_id": [
41796394
],
"json.exception.backtrace": [
"lib/bitbucket/representation/issue.rb:9:in `iid'",
"lib/gitlab/bitbucket_import/importer.rb:75:in `allocate_issues_internal_id!'",
"lib/gitlab/bitbucket_import/importer.rb:97:in `import_issues'",
"lib/gitlab/bitbucket_import/importer.rb:24:in `execute'",
"app/services/projects/import_service.rb:134:in `import_data'",
"app/services/projects/import_service.rb:25:in `execute'",
"app/services/concerns/measurable.rb:35:in `execute'",
"app/workers/repository_import_worker.rb:28:in `perform'",
"ee/app/workers/ee/repository_import_worker.rb:9:in `perform'",
"lib/gitlab/database/load_balancing/sidekiq_server_middleware.rb:26:in `call'",
"lib/gitlab/sidekiq_middleware/duplicate_jobs/strategies/until_executing.rb:16:in `perform'",
(snipped for brevity)
],
"json.exception.message": [
"undefined method `[]' for nil:NilClass"
],
"json.correlation_id": [
"01GM3JARZ5RS5BWFH9BTEF75AT"
],
}
}Output of checks
This bug happens on GitLab.com /label reproduced on GitLab.com
Results of GitLab environment / application info
GitLab.com says it's at 15.7.0-pre d13fae33516 right now. So that I guess and whatever else it's got going on.
Possible fixes
The backtrace takes me here:
I think the nil happens when we get the IID for the issue:
That allocate_issues_internal_id! method thing was added just last month:
It seems to want to exit early if no issues are returned from Bitbucket. So the customer ran the same GET request that our importer client makes to see what we got:
In their case a GET to https://api.bitbucket.org/2.0/repositories/GROUP_HERE/PROJECT_SLUG/issues?pagelen=1&sort=-created_on&state=ALL returned an empty list for their repo with a private issue tracker. So something in the short circuit isn't actually exiting when it should and letting this nil squeak through. One of those checking the existence of the list and not actually if there's stuff in the list type situations perhaps.
Possible workaround
Turning it off the issue tracker entirely in Bitbucket settings allowed the import to complete successfully since that just skips the issue section. If you care about the issues making the Bitbucket tracker public might work too, but the customer and I didn't test that.