fix(jira): Only load saved project status mappings - #120481
Conversation
github-actions
Bot
added
the
Scope: Backend
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
When `organizations:jira-lazy-status-sync` is enabled, pre-load statuses only for already-configured projects (via IntegrationExternalProject) and provide a `statusUrl` in the config for the frontend to lazy-load statuses for new projects. When the flag is off, existing threshold-based behavior is unchanged. ISWF-1684
Rename _set_lazy_status_choices_in_organization_config to _get_lazy_status_config and have it return a dict that the caller merges, rather than mutating the configuration list in place.
c609d29 to
0104ea0
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 0104ea0. Configure here.
| "values", [] | ||
| ) | ||
| except ApiError: | ||
| continue |
There was a problem hiding this comment.
Status fetch errors leave empty choices
Medium Severity
_get_lazy_status_config catches ApiError per project and continues, so failed status fetches omit that project from mappedSelectors while the form stays enabled. The non-lazy path re-raises and disables the field with an error message. Users can see configured mappings with empty status dropdowns and no indication that Jira communication failed.
Reviewed by Cursor Bugbot for commit 0104ea0. Configure here.
There was a problem hiding this comment.
tradeoff is intentional so that we are able to load the other ones
| mapped_selectors[project.external_id] = { | ||
| "on_resolve": {"choices": statuses}, | ||
| "on_unresolve": {"choices": statuses}, | ||
| } |
There was a problem hiding this comment.
Unbounded per-project status requests
Medium Severity
_get_lazy_status_config issues one serial get_project_statuses call for every saved IntegrationExternalProject with no cap. The existing path limits per-project queries via MAX_PER_PROJECT_QUERIES specifically to avoid Atlassian rate limits. Orgs with many configured mappings can hit timeouts or rate limits when loading config.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 0104ea0. Configure here.
There was a problem hiding this comment.
Realistically i dont think we'll go over like 10 projects
2 participants
Instead of fetching and loading all of the project status mappings. Load only the ones that are currently configured. We will dynamically fetch other project statuses when they are added (see PR 1 of stack)
Step 2 of lazy loading Jira project statuses