Repository navigation
fix(alerts): read issue alert rules from org-scoped /workflows/ - #1215
Merged
Merged
Conversation
The project-scoped `/projects/{org}/{project}/rules/` endpoint was deprecated on
2026-05-14 and now returns HTTP 410 during recurring brownouts, breaking `sentry
alert issues list` and `view` (getsentry/cli#1182).
Migrate the read path to the org-scoped `/organizations/{org}/workflows/` endpoint,
filtered by `projectSlug` (and `id` for single-rule reads), mirroring sentry-mcp.
The endpoint returns rule-shaped payloads, so the existing `IssueAlertRule` shape is
preserved; add `detectorIds` and drop unattached org-level workflows via
`filterAttachedIssueAlertRules`. `getIssueAlertRule` now throws a 404 ApiError when no
attached rule matches, keeping `isNotFoundApiError` resolution working.
Mutations (create/update/delete) still use the legacy endpoint pending a follow-up.
Verified: tsc + biome clean; alert/api/command suites pass (added HTTP-level tests for
the workflows list/get + 404); live `alert issues list` and `view` against a real org
return rules with no 410 exposure.
Refs GH-1182
Co-Authored-By: Claude <noreply@anthropic.com>
Contributor
|
Contributor
Codecov Results 📊✅ Patch coverage is 100.00%. Project has 5337 uncovered lines. Files with missing lines (1)
Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
+ Coverage 81.80% 81.81% +0.01%
==========================================
Files 423 423 —
Lines 29338 29343 +5
Branches 19113 19117 +4
==========================================
+ Hits 24000 24006 +6
- Misses 5338 5337 -1
- Partials 1987 1989 +2Generated by Codecov Action |
betegon
marked this pull request as ready for review
July 9, 2026 15:21
This was referenced Jul 9, 2026
betegon
added a commit
that referenced
this pull request
Jul 9, 2026
## What & why
Second slice of migrating issue alerts off the deprecated (HTTP 410
brownout) project-scoped `/projects/{org}/{project}/rules/` endpoint
(#1182). The read path (`list`/`view`) landed in #1215; this migrates
**delete**.
`deleteIssueAlertRule` now issues `DELETE
/organizations/{org}/workflows/{id}/`.
- The id is the **workflow id** already surfaced by the migrated read
path (that's what `list`/`view` show and what `getIssueAlertRule`'s
`?id=` filter matches), and `alert issues delete` resolves the rule
before deleting, so the delete is correctly keyed by id.
- `projectSlug` is kept for signature parity with `getIssueAlertRule`
but is unused (workflow delete is by id; project scoping happens
upstream at resolve time).
## Scope
**Delete only.** Create and edit are a distinct, larger follow-up: the
workflows write endpoint expects a workflow-document body
(`triggers`/`action_filters`/`detector_ids`) with different
condition/action item schemas than the legacy rule identifiers users
pass via `--condition`/`--action` today. Faithfully translating that
client-side is impractical (the backend does it in
`issue_alert_dual_write.py`), and it would be a breaking
`--condition`/`--action` contract change plus a `detector_ids`
resolution step. Tracked on #1182.
## Test plan
- `tsc --noEmit` + `biome check`: clean.
- `vitest run test/lib/api/alerts.test.ts test/commands/alert`: green.
Updated the api-level delete test to assert the workflows DELETE URL;
the command test mocks the api-client function so it is transparent to
the endpoint change.
- Live delete is destructive (needs a real rule), so it's not run in CI;
the api test pins the exact `DELETE
/organizations/{org}/workflows/{id}/` request.
Refs #1182
---------
Co-authored-by: Claude <noreply@anthropic.com>
This was referenced Jul 22, 2026
BYK
pushed a commit
that referenced
this pull request
Jul 24, 2026
Migrates the metric-alert **read** path (`list` / `view` / rule
resolution) off the legacy `/organizations/{org}/alert-rules/` endpoint
— which is being retired on **2026-08-17** and 410s during brownouts —
to the new org-scoped `/organizations/{org}/detectors/` endpoint
filtered to `type:metric_issue`. A `mapDetectorToMetricAlertRule` helper
flattens the nested detector payload into the existing `MetricAlertRule`
shape, so command formatters and resolvers work unchanged.
This mirrors the proven issue-alert read migration (#1215/#1216).
Metric-alert **mutations** (`create`/`edit`/`delete`) still use the
legacy endpoint pending the follow-up mutation migration tracked in
#1277 — same transitional state as issue alerts today.
## Testing
- `pnpm run typecheck` — clean
- `pnpm run lint` — clean
- `npx vitest run test/lib/api/alerts.test.ts test/commands/alert` — 150
passing (updated metric-list mocks to `/detectors/`; added list/get +
nested-`snubaQuery` mapping tests)
Refs #1274, #1182
<!--
## Plan
Scope: incremental slice of #1274, matching the established #1215/#1216
pattern
(migrate read path first, defer mutations).
Root cause: metric-alert list/view/get still hit the deprecated
/organizations/{org}/alert-rules/ endpoint, retired 2026-08-17.
Changes (src/lib/api/alerts.ts):
- Add MetricDetector type (only CLI-read fields typed;
dataSources/config opaque).
- Add mapDetectorToMetricAlertRule: id=String(detector.id),
status=enabled===false?1:0,
threshold fields from dataSources[0] with queryObj/snubaQuery fallback,
owner
flattened, projects/dateCreated defaulted.
- listMetricAlertsPaginated -> GET
/organizations/{org}/detectors/?query=type:metric_issue&sortBy=-id then
map.
- getMetricAlertRule -> GET /organizations/{org}/detectors/{id}/ then
map.
- Leave
fetchMetricAlertRuleJson/getMetricAlertRuleDocument/put*/delete*/create*
on legacy /alert-rules/.
Tests updated: alerts.test.ts (fixture + list/get/snubaQuery mapping),
metrics/list.test.ts
(detector() builder; repoint mocks/regexes/endpoint assertions to
/detectors/).
Known transitional caveat (matches issue-alert precedent): edit resolves
via the migrated
detector read but still PUTs against legacy /alert-rules/{id}/; resolved
by the deferred
mutation migration.
-->
---------
Co-authored-by: jared-outpost[bot] <jared-outpost[bot]@users.noreply.github.com>
5 tasks
jared-outpost Bot
added a commit
that referenced
this pull request
Aug 1, 2026
…ows/
Final slice of migrating issue alerts off the deprecated (HTTP 410
brownout) project-scoped /projects/{org}/{project}/rules/ endpoint
(#1182), after read (#1215) and delete (#1216). This migrates create and
edit.
create/edit now go through the @sentry/api SDK (createOrganizationWorkflow
/ updateOrganizationWorkflow), assembling the workflow-document body:
triggers {logicType, conditions}, actionFilters[{logicType, conditions,
actions}], config.frequency, and detectorIds resolved from the project's
error detector. --action-match/--filter-match map to logic types the same
way the backend dual-write does (any -> any-short, all -> all).
The SDK types conditions/actions as unknown[] and its body fields as
snake_case, but the endpoint's CamelSnakeSerializer wants camelCase, so
the body is built as a record and cast into the typed SDK arg (same
double-cast pattern as getProject). No backend change needed.
BREAKING CHANGE: --condition/--action/--filter now take workflow-native
JSON ({type, comparison, conditionResult} / {type, data, config}) instead
of legacy rule identifiers ({id: 'sentry.rules...'}).
Refs #1182
jared-outpost Bot
added a commit
that referenced
this pull request
Aug 1, 2026
…ows/ (#1223) ## What & why Final slice of migrating issue alerts off the deprecated (HTTP 410 brownout) project-scoped `/projects/{org}/{project}/rules/` endpoint (#1182), after read (#1215) and delete (#1216). This migrates **create** and **edit**. `create`/`edit` now go through the `@sentry/api` SDK (`createOrganizationWorkflow` / `updateOrganizationWorkflow`), assembling the workflow-document body: - `triggers: { logicType, conditions }` from `--condition` / `--action-match` - `actionFilters: [{ logicType, conditions, actions }]` from `--filter` / `--filter-match` / `--action` - `config.frequency` from `--frequency` - `detectorIds` resolved from the project's **error detector** (an issue alert has to attach to it to fire) via `listOrganizationDetectors(?project=…&query=type:error)` `--action-match` / `--filter-match` map to `DataConditionGroup` logic types the same way the backend dual-write does (`any` → `any-short`, `all` → `all`). `edit` reads the workflow document (`getOrganizationWorkflow`), applies the flag overrides in workflow shape (`--status` → `enabled`), and PUTs it back. The SDK types conditions/actions as `unknown[]` and its body fields as snake_case, but the endpoint's `CamelSnakeSerializer` wants camelCase — so the body is built as a record and cast into the typed SDK arg, the same double-cast pattern as `getProject`. No backend change needed. ## Breaking change `--condition` / `--action` / `--filter` now take **workflow-native JSON** (`{type, comparison, conditionResult}` / `{type, data, config}`) instead of the legacy rule identifiers (`{id: "sentry.rules..."}`). The `--help` examples are updated accordingly. ## Scope Read/delete (merged in #1215/#1216) use `apiRequestToRegion`; create/edit here use the `@sentry/api` SDK + cast, matching the projects-domain SDK adoption (#1213). Minor inconsistency within `alerts.ts`, intentional — this is the SDK-adoption direction. ## Test plan - `tsc --noEmit` + `biome check`: clean. - `vitest run test/lib/api/alerts.test.ts test/commands/alert`: green (19 tests). API-level tests pin the exact workflow create/update/detector requests via `mockFetch`; command tests mock the api-client so they are transparent to the mechanism. - **Not yet run live.** The unit tests mock the API, so three things still need a real create/edit to confirm: (1) the edit read-modify-write round-trips through the workflows PUT, (2) `config.frequency` unit (minutes, per the CLI flag), (3) `query=type:error` returns the project error detector. Refs #1182 --------- Co-authored-by: jared-outpost[bot] <jared-outpost[bot]@users.noreply.github.com>
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.
What & why
The project-scoped
/projects/{org}/{project}/rules/endpoint was deprecated on 2026-05-14 and now returns HTTP 410 during recurring brownouts (every ~2h), breakingsentry alert issues listandviewfor users. Fixes the read path per getsentry/toolkit#1482.Change
Migrate the read functions in
src/lib/api/alerts.tsto the org-scoped/organizations/{org}/workflows/endpoint, mirroring the provensentry-mcpimplementation:listIssueAlertsPaginated→GET /organizations/{org}/workflows/?projectSlug={project}&sortBy=-idgetIssueAlertRule→GET /organizations/{org}/workflows/?projectSlug={project}&id={id}&per_page=1, throwing a 404ApiErrorwhen no attached rule matches (keepsisNotFoundApiErrorresolution working).The workflows endpoint returns rule-shaped payloads, so the existing
IssueAlertRuletype is preserved. AddeddetectorIdsto the type and afilterAttachedIssueAlertRuleshelper to drop unattached org-level workflows (aprojectSlug-filtered response can include them).Scope
Reads only. Mutations (
create/edit/delete) still use the legacy endpoint and are a tracked follow-up — the workflows create/update body shape differs and has no MCP reference yet.getReplayRecordingSegments/getTraceItemDetailare out of scope (not deprecated; blocked on getsentry/sentry#118963).Test plan
tsc --noEmit+biome check: clean.list.test.tsmocks to the workflows endpoint withdetectorIds.alert issues listreturns attached rules;alert issues view <id>returns the rule; a bogus id yieldsIssue alert rule '…' not found— no 410 exposure.Refs getsentry/toolkit#1482