fix: don't abort init when board fetch fails on Jira Cloud - #21
Merged
Conversation
Jira Cloud can return a 500 (instead of an empty list) when fetching boards for a project that doesn't support Jira Software boards, e.g. a Business/JWM project. `jira init` already treats "no boards available" as a normal case for local/server installs by falling back to a "None" option, but hard-aborted for Cloud instead. Apply the same graceful fallback for Cloud, since credentials are already verified earlier in the init flow via `Me()`.
rethab
added a commit
that referenced
this pull request
Aug 5, 2026
Jira Cloud can return a 500 Internal Server Error (instead of an empty list) when `jira init` fetches boards for a project that doesn't support Jira Software boards, e.g. a Business/JWM project. This is a known quirk on Jira's side, not something the CLI can fix server-side. The existing code in `getBoardSuggestions` already handles the "no boards available" case gracefully for local/on-prem installs by falling back to a "None" board option (added to handle installs without the agile add-on returning 404), but for Cloud it special-cased the error and aborted `init` entirely, leaving the user unable to finish setup at all. This change drops the Cloud-specific hard-fail and applies the same fallback used for local instances: if the board fetch fails, skip it and offer "None" as the board choice. The fallback is no longer silent: a warning including the response status (e.g. `500 Internal Server Error`) is printed so users can tell why only "None" is offered. This is safe because credentials and server details are already validated earlier in the init flow via `Me()`, so a failed board fetch at this point reflects the project/board API, not auth. Addresses ankitpokhrel#1001.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jira Cloud can return a 500 Internal Server Error (instead of an empty list) when
jira initfetches boards for a project that doesn't support Jira Software boards, e.g. a Business/JWM project. This is a known quirk on Jira's side, not something the CLI can fix server-side.The existing code in
getBoardSuggestionsalready handles the "no boards available" case gracefully for local/on-prem installs by falling back to a "None" board option (added to handle installs without the agile add-on returning 404), but for Cloud it special-cased the error and abortedinitentirely, leaving the user unable to finish setup at all.This change drops the Cloud-specific hard-fail and applies the same fallback used for local instances: if the board fetch fails, skip it and offer "None" as the board choice. The fallback is no longer silent: a warning including the response status (e.g.
500 Internal Server Error) is printed so users can tell why only "None" is offered. This is safe because credentials and server details are already validated earlier in the init flow viaMe(), so a failed board fetch at this point reflects the project/board API, not auth.Addresses ankitpokhrel#1001.