Skip to content

"Path has already been taken" error when trying to re-import Bitbucket Repositories into the same group

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

When attempting to re-import Bitbucket repositories from Bitbucket Server into the same group, it always fails with Path has already been taken despite the new target path being empty. After reproducing using the steps below, I've captured the following logs:

importer.log
22:{"feature_category":"importers","severity":"ERROR","time":"2023-11-02T17:21:49.581Z","correlation_id":"01HE8GWD7RTNN3V5N3BGBETMGB","meta.caller_id":"Import::BitbucketServerController#create","meta.remote_ip":"23.114.197.183","meta.feature_category":"importers","meta.user":"root","meta.user_id":1,"meta.client_id":"user/1","message":"Import failed due to a BitBucket Server error","error":"Path has already been taken"}

application_json.log
416:{"severity":"ERROR","time":"2023-11-02T17:21:49.574Z","correlation_id":"01HE8GWD7RTNN3V5N3BGBETMGB","meta.caller_id":"Import::BitbucketServerController#create","meta.remote_ip":"23.114.197.183","meta.feature_category":"importers","meta.user":"root","meta.user_id":1,"meta.project":"bitbucket-testing-group/juice-shop","meta.root_namespace":"bitbucket-testing-group","meta.client_id":"user/1","message":"Unable to save project. Error: Path has already been taken"}

production_json.log
11541:{"method":"POST","path":"/import/bitbucket_server.json","format":"json","controller":"Import::BitbucketServerController","action":"create","status":422,"time":"2023-11-02T17:21:49.583Z","params":[{"key":"repo_id","value":"TP/juice-shop"},{"key":"ci_cd_only","value":false},{"key":"new_name","value":"juice-shop-10000"},{"key":"target_namespace","value":"bitbucket-testing-group"},{"key":"bitbucket_server","value":{"repo_id":"TP/juice-shop","ci_cd_only":false,"new_name":"juice-shop-10000","target_namespace":"bitbucket-testing-group"}}],"correlation_id":"01HE8GWD7RTNN3V5N3BGBETMGB","meta.caller_id":"Import::BitbucketServerController#create","meta.remote_ip":"23.114.197.183","meta.feature_category":"importers","meta.user":"root","meta.user_id":1,"meta.client_id":"user/1","remote_ip":"23.114.197.183","user_id":1,"username":"root","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36","queue_duration_s":0.019924,"request_urgency":"low","target_duration_s":5,"redis_calls":11,"redis_allowed_cross_slot_calls":1,"redis_duration_s":0.007091999999999999,"redis_read_bytes":575,"redis_write_bytes":1213,"redis_cache_calls":3,"redis_cache_duration_s":0.00291,"redis_cache_read_bytes":117,"redis_cache_write_bytes":179,"redis_rate_limiting_calls":3,"redis_rate_limiting_duration_s":0.002293,"redis_rate_limiting_read_bytes":4,"redis_rate_limiting_write_bytes":340,"redis_sessions_calls":3,"redis_sessions_allowed_cross_slot_calls":1,"redis_sessions_duration_s":0.001304,"redis_sessions_read_bytes":454,"redis_sessions_write_bytes":590,"redis_shared_state_calls":2,"redis_shared_state_duration_s":0.000585,"redis_shared_state_write_bytes":104,"db_count":24,"db_write_count":0,"db_cached_count":7,"db_replica_count":0,"db_primary_count":24,"db_main_count":24,"db_ci_count":0,"db_main_replica_count":0,"db_ci_replica_count":0,"db_replica_cached_count":0,"db_primary_cached_count":7,"db_main_cached_count":7,"db_ci_cached_count":0,"db_main_replica_cached_count":0,"db_ci_replica_cached_count":0,"db_replica_wal_count":0,"db_primary_wal_count":0,"db_main_wal_count":0,"db_ci_wal_count":0,"db_main_replica_wal_count":0,"db_ci_replica_wal_count":0,"db_replica_wal_cached_count":0,"db_primary_wal_cached_count":0,"db_main_wal_cached_count":0,"db_ci_wal_cached_count":0,"db_main_replica_wal_cached_count":0,"db_ci_replica_wal_cached_count":0,"db_replica_duration_s":0.0,"db_primary_duration_s":0.025,"db_main_duration_s":0.025,"db_ci_duration_s":0.0,"db_main_replica_duration_s":0.0,"db_ci_replica_duration_s":0.0,"external_http_count":2,"external_http_duration_s":0.06644894101191312,"cpu_s":0.188755,"mem_objects":44234,"mem_bytes":3109478,"mem_mallocs":12835,"mem_total_bytes":4878838,"pid":106022,"worker_id":"puma_1","rate_limiting_gates":["project_import"],"db_duration_s":0.02346,"view_duration_s":0.00032,"duration_s":0.23767}

In the case above, I attempted to import a test juice-shop project. It succeeded the first time around. If I tried to re-import and appended any number like juice-shop-2 or juice-shop-1000 it would fail. If you change the group itself, then it will work. Here is to confirm that the original path exists, but not the new path:

irb(main):001:0> Project.find_by_full_path("bitbucket-testing-group/juice-shop-2")
=> nil
irb(main):002:0> Project.find_by_full_path("bitbucket-testing-group/juice-shop")
=> #<Project id:11 bitbucket-testing-group/juice-shop>>

A 422 is seen in the logs and in the browser console:

Failed to load resource: the server responded with a status of 422 ()
xhr.js:210 
        
POST https://hostname.net/import/bitbucket_server.json 422 (Unprocessable Content)

Enabling debug logging on the Bitbucket Server didn't produce any errors, just authentication messages:

DEBUG [http-nio-7990-exec-6] @7XISRx1025x4257x0 <ip_address> "GET /rest/api/1.0/repos HTTP/1.1" c.a.s.i.user.DefaultUserService admin: Returning active from cache
DEBUG [http-nio-7990-exec-6] @7XISRx1025x4257x0 <ip_address> "GET /rest/api/1.0/repos HTTP/1.1" c.a.s.i.a.DefaultAuthenticationService admin: Authenticator 'com.atlassian.bitbucket.server.bitbucket-access-tokens:accessTokenHttpAuthHandler' authenticated admin (2)
DEBUG [http-nio-7990-exec-9] @7XISRx1025x4258x0 <ip_address> "GET /rest/api/1.0/repos HTTP/1.1" c.a.b.i.c.s.CrowdSsoAuthenticationHandler Skipping Crowd SSO as it is not enabled
DEBUG [http-nio-7990-exec-9] @7XISRx1025x4258x0 <ip_address> "GET /rest/api/1.0/repos HTTP/1.1" c.a.s.i.a.DefaultAuthenticationService admin: Authenticator 'com.atlassian.bitbucket.server.bitbucket-crowd-sso:crowdSsoAuthHandler' opted out
DEBUG [http-nio-7990-exec-9] @7XISRx1025x4258x0 <ip_address> "GET /rest/api/1.0/repos HTTP/1.1" c.a.s.i.a.DefaultAuthenticationService admin: Authenticator 'com.atlassian.bitbucket.server.bitbucket-git-lfs:git-lfs-jwt-auth-handler' opted out

Seemingly upon import execution we return the error for unprocessable_entity. It's possible we are not properly requesting the new path and trying to execute it against the old path.

Steps to reproduce

  1. Set up a Bitbucket Server. Version 7.21.7 was used in this case.
  2. Create or import a repository into Bitbucket for testing.
  3. Create a PAT for the admin user.
  4. Create a new project on the GitLab Server (v16.5 was used in testing) and select Import Project > Bitbucket Server
  5. Enter the Bitbucket Server URL, Username (admin), and PAT that was generated. List the server repositories.
  6. Import the test project into any group and namespace. The first time it should succeed.
  7. Try to re-import without changing the project path. It should fail with Importing the project failed: Project namespace name has already been taken, Name has already been taken, Path has already been taken. as expected.
  8. Try to change the project path to anything else that doesn't exist. It will always fail with Path has already been taken
  9. Change the group to a different group or sub-group and this should work.

What is the current bug behavior?

Trying to re-import a project via the Bitbucket Server importer always fails with Path has already been taken when importing into the same group.

What is the expected correct behavior?

You should be able to change the path and re-import into a new project path.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

System information
System:		Ubuntu 20.04
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	3.0.6p216
Gem Version:	3.4.19
Bundler Version:2.4.20
Rake Version:	13.0.6
Redis Version:	7.0.13
Sidekiq Version:6.5.7
Go Version:	unknown

GitLab information
Version:	16.5.0-ee
Revision:	fc87c9d4cca
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	13.11
URL:		https://hostname
HTTP Clone URL:	https://hostname/some-group/some-project.git
SSH Clone URL:	git@hostname:some-group/some-project.git
Elasticsearch:	yes
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers: openid_connect

GitLab Shell
Version:	14.29.0
Repository storages:
- default: 	unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell

Gitaly
- default Address: 	unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version: 	16.5.0
- default Git Version: 	2.42.0

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 14.29.0 ? ... OK (14.29.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 1/1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Reply by email is disabled in config/gitlab.yml


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab App ...


Database config exists? ... yes
Tables are truncated? ... skipped
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Cable config exists? ... yes
Resque config exists? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Projects have namespace: ...
2/1 ... yes
7/2 ... yes
10/3 ... yes
7/4 ... yes
16/5 ... yes
23/6 ... yes
23/7 ... yes
25/8 ... yes
29/9 ... yes
1/10 ... yes
33/11 ... yes
27/12 ... yes
Redis version >= 6.0.0? ... yes
Ruby version >= 3.0.6 ? ... yes (3.0.6)
Git user has default SSH configuration? ... yes
Active users: ... 5
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x-8.x or OpenSearch version 1.x ... yes (elasticsearch 8.9.2)
All migrations must be finished before doing a major upgrade ... no (You have 25 pending migrations.)
For more information see:
https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html#all-migrations-must-be-finished-before-doing-a-major-upgrade
Try fixing it:
Wait for all advanced search migrations to complete.
To list pending migrations, run sudo gitlab-rake gitlab:elastic:list_pending_migrations


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Workaround

If you change the group to a completely different group, the project will re-import.

Possible fixes

Edited by 🤖 GitLab Bot 🤖