Description
The buildProjectAliasMap function in src/commands/issue/list.ts generates aliases that collide when multiple organizations have projects with the same slug. This causes the entries dictionary to lose one of the projects, making its issues inaccessible via alias shortcuts.
Root Cause
The alias generation logic (lines 141-170) only considers project slugs when computing unique prefixes, ignoring the organization. The entries dictionary is keyed by alias alone, so when two projects from different orgs generate the same alias, the second overwrites the first.
// Line 142: Collects only project slugs, ignoring org
const projectSlugs = results.map((r) => r.target.project);
// Lines 166-169: entries keyed by alias - collisions overwrite
entries[alias] = {
orgSlug: result.target.org,
projectSlug,
};
Reproduction
- Set up a monorepo with two Sentry DSNs from different organizations, where both projects have the same slug (e.g.,
org1:dashboard and org2:dashboard)
- Run
sentry issue list
- Both projects' issues appear with the same alias prefix (e.g.,
d-A3, d-B7)
- Run
sentry issue get d-A3 (an issue from org1)
- The CLI looks up alias
d → returns org2's project → fails to find the issue or returns wrong data
Expected Behavior
Each project should have a unique alias, even when slugs collide across organizations. For example:
org1:dashboard → o1-d
org2:dashboard → o2-d
Severity
Medium - This is an edge case requiring multi-org monorepos with identical project slugs. Workaround: use explicit --org and --project flags.
References
Suggested Fix
Modify buildProjectAliasMap to:
- Detect slug collisions across orgs
- For colliding slugs, include org abbreviation in the alias to ensure uniqueness
- For unique slugs, keep the existing short alias behavior
Description
The
buildProjectAliasMapfunction insrc/commands/issue/list.tsgenerates aliases that collide when multiple organizations have projects with the same slug. This causes theentriesdictionary to lose one of the projects, making its issues inaccessible via alias shortcuts.Root Cause
The alias generation logic (lines 141-170) only considers project slugs when computing unique prefixes, ignoring the organization. The
entriesdictionary is keyed by alias alone, so when two projects from different orgs generate the same alias, the second overwrites the first.Reproduction
org1:dashboardandorg2:dashboard)sentry issue listd-A3,d-B7)sentry issue get d-A3(an issue from org1)d→ returns org2's project → fails to find the issue or returns wrong dataExpected Behavior
Each project should have a unique alias, even when slugs collide across organizations. For example:
org1:dashboard→o1-dorg2:dashboard→o2-dSeverity
Medium - This is an edge case requiring multi-org monorepos with identical project slugs. Workaround: use explicit
--organd--projectflags.References
Suggested Fix
Modify
buildProjectAliasMapto: