ref(crons): Reorganize incident creation / issue occurrence logic

[ShashankFC]

User description

Test 8

Summary by CodeRabbit

Release Notes

• New Features
  • Implemented automatic incident creation and detection for monitor failures, respecting configurable failure thresholds.
  • Enhanced incident context with human-readable failure reason summaries, environment details, and tracking of last successful check-in times to aid in incident diagnosis and resolution.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

---

Replicated from ai-code-review-evaluation/sentry-coderabbit#8

---

CodeAnt-AI Description

Send readable incident occurrences to the issue pipeline when monitors fail

What Changed

• When a monitor reaches its failure threshold, an incident is created (or reused) and one or more issue occurrences are produced and sent to the issue pipeline for each failed check-in that triggered the incident.
• Occurrences include human-readable failure reasons (e.g., "3 missed check-ins detected"), environment name, and the timestamp of the last successful check-in to help diagnose failures.
• No occurrences are produced if the monitor or its environment is muted; the existing monitor_environment_failed signal is still emitted after marking a failure.

Impact

✅ Clearer incident evidence for monitor failures
✅ More actionable issue occurrences in the issue pipeline
✅ Fewer irrelevant occurrences when monitors or environments are muted

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[ShashankFC]

@CodeAnt-AI: review

[codeant-ai]

CodeAnt AI is running the review.

[codeant-ai]

Suggestion: The monitor environment context builds a modified copy of the monitor config with a human-readable schedule type but then returns the original unmodified config, so the computed change is silently discarded and the context never contains the intended humanized schedule information; the function should return the modified config instead. [logic error]

Severity Level: Major ⚠️

- ⚠️ Monitor incident context contains numeric schedule_type, not string.
- ⚠️ Inconsistent schedule representation vs MonitorSerializer API responses.
- ⚠️ Redundant config.copy() logic; intended humanization unused.

Suggested change

	"config": monitor_environment.monitor.config,
	"config": config,

Steps of Reproduction ✅

1. Create or use any cron monitor; its config schema in
`src/sentry/monitors/models.py:49-63` (`MONITOR_CONFIG`) requires an integer
`schedule_type`, and `Monitor.get_schedule_type_display()` at
`src/sentry/monitors/models.py:343-344` defines the human-readable string mapping.

2. Let that monitor's check-ins fail until an incident is created; the incident creation
logic in `src/sentry/monitors/logic/incidents.py:7,95` imports and calls
`create_incident_occurrence(...)` with the failing `MonitorEnvironment` instance.

3. Inside `create_incident_occurrence` in
`src/sentry/monitors/logic/incident_occurrence.py:28-113`, the code builds `event_data`
and sets `"contexts": {"monitor": get_monitor_environment_context(monitor_env)}` at line
89, so the monitor context used in the issue occurrence comes from
`get_monitor_environment_context`.

4. `get_monitor_environment_context` at
`src/sentry/monitors/logic/incident_occurrence.py:159-171` copies
`monitor_environment.monitor.config` to a local `config`, replaces
`config["schedule_type"]` with `monitor_environment.monitor.get_schedule_type_display()`
(lines 160-162), but then returns a dict with `"config":
monitor_environment.monitor.config` (original, unmodified) instead of the updated
`config`, so the `event_data["contexts"]["monitor"]["config"]["schedule_type"]` value
remains the raw integer and the computed human-readable value is silently discarded,
unlike `MonitorSerializer` in `src/sentry/monitors/serializers.py:239-252` which correctly
returns the modified `config`.

Prompt for AI Agent 🤖

This is a comment left during a code review.

**Path:** src/sentry/monitors/logic/incident_occurrence.py
**Line:** 168:168
**Comment:**
	*Logic Error: The monitor environment context builds a modified copy of the monitor config with a human-readable schedule type but then returns the original unmodified config, so the computed change is silently discarded and the context never contains the intended humanized schedule information; the function should return the modified `config` instead.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.

👍 | 👎

[codeant-ai]

Nitpicks 🔍

🔒 No security issues identified

⚡ Recommended areas for review Incorrect config returned The function get_monitor_environment_context copies and mutates a local config variable but returns monitor_environment.monitor.config (the original), so any adjustments applied to config (e.g. human readable schedule_type) are not included in the returned context. This likely causes the context to be stale or missing expected human-friendly values. Deferred QuerySet evaluation / potential ordering bug The code casts a .values(... ) QuerySet to a list via cast(...) but does not actually materialize it before slicing/reversing. Using reversed(previous_checkins[:n]) on an unevaluated QuerySet can be surprising and may lead to inefficiencies or unexpected behavior. The code should explicitly evaluate the QuerySet into a list before slicing/reversing.

[codeant-ai]

CodeAnt AI finished running the review.