Repository navigation
feat(logs): start a team's first logs alert on the alerts platform - #127773
Conversation
A new logs alert went to the platform only once the platform owned another of the team's alerts, so a team creating its first alert stayed on logs. The platform now owns a new alert unless the team has other logs alerts and none of them is on the platform, which keeps a rolled-back team on logs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
😎 Merged successfully - details. |
|
Risk: No findings This PR changes where a team's new logs alert starts: the alerts platform now owns it unless the team's other alerts all stay on logs (e.g. a rolled-back team), replacing the old rule that required the platform to already own one of the team's alerts. The change is a team-scoped routing decision with no new endpoints, inputs, or authorization surfaces, and I found no security impact. Sentinel reviewed |
There was a problem hiding this comment.
PostHog Review · Standard · reviewed 6319b7c: 1 Should fix.
This is the only automatic review while this pull request is a draft. Comment @posthog review to review new changes sooner. Otherwise, a review of the new changes runs when you mark it ready for review.
See this review and its findings in PostHog Review. Comment @posthog review --deep for a Deep review. A Deep review takes longer and looks deeper than a Standard review.
There was a problem hiding this comment.
Not approved — this change needs a human reviewer.
Re-add the stamphog label to request another review once you have addressed this.
The author's ownership and STRONG familiarity provide assurance, but @PostHog's substantive rollback concern remains unresolved. Preserve rollback state independently of remaining alerts and add deletion-and-recreation coverage, then request review from @PostHog/team-apm before re-requesting.
- Author wrote 100% of the modified lines and has 24 merged PRs in these paths (familiarity STRONG).
- PostHog Review (Standard) reviewed the current head: 1 finding, posted on the PR.
- posthog[bot] reviewed the current head.
- @PostHog, products/logs/backend/platform_cutover.py: rollback persistence remains unfixed. roll_back_team only updates existing alert rows; delete_alert physically deletes those rows (products/logs/backend/alert_deletion.py:39). After the last rolled-back alert is deleted, takes_new_alert sees no other owners and assigns the replacement to the platform, reversing the team's rollback.
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 31L, 3F substantive, 82L/4F incl. docs/generated/snapshots — within ceiling |
| tier | ✓ | T1-agent / T1b-small (82L, 4F, single-area, feat) |
| stamphog 2.7.0 | .stamphog/policy.yml @ 6319b7c · reviewed head 6319b7c |
🤖 CI report
|
There was a problem hiding this comment.
Approved.
The risky write-path change has owning-team and STRONG-familiarity assurance, with regression coverage. The current-head review reports an unspecified finding but supplies no substantive concern to verify; it is not counted as a concern-free review.
- Author wrote 100% of the modified lines and has 24 merged PRs in these paths (familiarity STRONG).
- PostHog Review (Standard) reviewed the current head: 1 finding, posted on the PR.
- posthog[bot] reviewed the current head.
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 31L, 3F substantive, 82L/4F incl. docs/generated/snapshots — within ceiling |
| tier | ✓ | T1-agent / T1b-small (82L, 4F, single-area, feat) |
| stamphog 2.7.0 | .stamphog/policy.yml @ 6319b7c · reviewed head 6319b7c |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
/trunk merge |
Problem
Changes
takes_new_alert: the platform owns a new logs alert unless the team has other logs alerts and none of them is on the platform.roll_back_logs_alerts_from_platformkeeps its new alerts on logs, as before.How did you test this code?
test_where_a_new_alert_startscovers four cases: a team's first alert, a team the platform owns alerts for, a team whose alerts are on logs, and a team rolled back withroll_back_team. Before this change, the first-alert case started on logs.Test rationale: the regression is a new team's first alert landing on legacy again, or a rolled-back team's new alert landing on the platform. The nearest test was the single platform-owned case, now parameterized.
Release status
Docs update
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Agent: Claude Code, Claude Opus 5.5
Skills:
/simplify,/code-review,/writing-pr-descriptions,/reviewing-with-coderabbitMore context for AI agents
products/alerts/backend/platform_ownership.pyalso checks that the platform can run the alert.--deepfound nothing./simplifymerged two owner queries into one; the rollback-flag suggestion went to follow-ups./code-reviewadded the rolled-back test case; three rollback edge cases were skipped as follow-ups or as predating this PR.🤖 Generated with Claude Code