## Summary When importing from a **Jira Server** instance with more than 1000 issues, the importer processes the first batch of 1000 issues correctly but never advances to subsequent pages. The import appears stuck indefinitely with "An import is in progress" shown in the UI. ## Steps to reproduce 1. Configure a Jira Server integration on a self-managed GitLab instance (Helm) 2. Start a Jira import on a project with >1000 issues 3. The first 1000 issues import correctly 4. The import stalls — no further issues are created, but IIDs keep incrementing (indicating the importer keeps re-processing/re-allocating without importing) 5. Confirm via Rails console: ```ruby Gitlab::JiraImport.get_pagination_state(project.id) # => {:is_last=>false, :next_page_token=>nil, :page=>1} ``` The page never advances beyond 1. ## Root cause Two bugs in combination: 1. `ServerListService#build_success_response` (`app/services/jira/requests/issues/server_list_service.rb`) was not including `page:` in its response payload. 2. `IssuesImporter#update_pagination_state` (`lib/gitlab/jira_import/issues_importer.rb`) stored `page: payload[:page]` (current page) instead of `page: payload[:page] + 1` (next page). Combined, this meant `get_pagination_state` always returned `page: 1`, causing `fetch_issues` to re-fetch the same first batch from Jira indefinitely. Issues were skipped via the `already_imported?` guard but IIDs kept being allocated via `Issue.with_namespace_iid_supply`, causing the IID inflation observed (jumping to 4000+ while only 1000 issues were actually created). ## Fix Two changes (already applied locally): ```diff diff --git a/app/services/jira/requests/issues/server_list_service.rb b/app/services/jira/requests/issues/server_list_service.rb index e9d1288c6c36..5510e9a01eb6 100644 --- a/app/services/jira/requests/issues/server_list_service.rb +++ b/app/services/jira/requests/issues/server_list_service.rb @@ -30,6 +30,7 @@ def build_success_response(response) ServiceResponse.success(payload: { issues: map_issues(response["issues"]), is_last: last?(response), + page: page, total_count: response["total"].to_i }) end diff --git a/lib/gitlab/jira_import/issues_importer.rb b/lib/gitlab/jira_import/issues_importer.rb index 46a2f5320284..081a61f7adcb 100644 --- a/lib/gitlab/jira_import/issues_importer.rb +++ b/lib/gitlab/jira_import/issues_importer.rb @@ -115,7 +115,7 @@ def update_pagination_state(payload) Gitlab::JiraImport.store_pagination_state(project.id, { is_last: payload[:is_last] || payload[:issues].blank? || payload[:issues].empty?, next_page_token: payload[:next_page_token], - page: payload[:page] + page: payload[:page] + 1 }) end ``` Patch file: [a.patch](https://gitlab.com/gitlab-org/gitlab/uploads/c8c25c25553cf7031ebd809c90a32a63/a.patch) ## TODO - [x] Add test to `spec/services/jira/requests/issues/server_list_service_spec.rb` verifying `page:` is included in the response payload - [x] Add test to `spec/lib/gitlab/jira_import/issues_importer_spec.rb` for Jira Server multi-page scenario: verify that after a batch completes, `get_pagination_state` advances to the next page and the subsequent `execute` call fetches page 2 - [x] Open MR with the fix + tests - [ ] Backport to affected stable branches ## Environment - GitLab Self-Managed (Helm chart) - Jira Server (`deployment_cloud? => false`) - ~3300 Jira issues to import ## Related Reported in https://gitlab.com/gitlab-org/gitlab/-/issues/217395#note_3112111740 Patch suggested in https://gitlab.com/gitlab-org/gitlab/-/issues/217395#note_3115698331