<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=25859) </details> <!--IssueSummary end--> https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22458#note_126192955 In `Import::GithubController#status` we get the provider repos to render the list of repos to import. There is a chance this request errors because of an invalid private token. A spec covers this. During https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22458 I moved a lot of this to be rendered on the clientside and moved all the query logic to a `respond_to` `:json` block. The one thing I didn't move is the error handling of that initial provider repos request. Because of this, we now call `client_repos` outside of the `respond_to` block to ensure that a user visiting the import table on a browser see's an error page. This isn't pretty as it requires a comment for the `client_repos` call to make sense. We should instead handle the private token validity error on the frontend by consuming a JSON error response. **Goal:** Remove `client_repos` call in `Import::GithubController#status` that is not a part of the `respond_to` block. Updated proposal: "So, I suggest maintaining the validation in the backend and renaming the method `client_repos` to `validate_access_token!` This will eliminate the need for the [code comment](https://gitlab.com/gitlab-org/gitlab/-/blob/b1aec8641c577a653288be5dbc20eca527f47758/app/controllers/import/github_controller.rb#L49-50) that currently explains the purpose of the method." see [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/25859#note_1819772715).