fix(code-review): Fix the audit log for code review settings

[suejungshin]

Fix the audit log shown for code review settings to have richer detail.

Existing:

New:
updated repository settings for getsentry/sentry (enabled code review)
updated repository settings for getsentry/sentry, getsentry/relay, getsentry/getsentry (disabled code review)
updated repository settings for org/repo (added code review on_ready_for_review)
updated repository settings for org/repo (removed code review on_new_commit)
updated repository settings for org/repo (added code review on_ready_for_review; removed code review on_new_commit)

someone bulk editing 200

[sentry]

Bug: Bulk-updating repositories with different existing triggers creates an inaccurate audit log. The previous_triggers set is aggregated across all repos, leading to incorrect change detection.
_{Severity: MEDIUM}

Suggested Fix

Instead of aggregating previous_triggers across all repositories, the logic should be changed. One option is to generate a more generic audit log message for bulk updates when initial states differ. Another, more accurate, approach would be to calculate the changes for each repository individually and either create separate audit log entries or a more detailed single entry that accurately reflects the distinct changes per repository.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location:
src/sentry/integrations/api/endpoints/organization_repository_settings.py#L94-L102

Potential issue: When bulk-updating code review settings for multiple repositories that
have different existing trigger configurations, the audit log entry is generated
incorrectly. The code aggregates all previous triggers from all repositories into a
single set, `previous_triggers`. This leads to an inaccurate calculation of which
triggers were added or removed, as the change is calculated against the combined set
rather than on a per-repository basis. For example, if one repository has a trigger
removed, the audit log will claim it was removed for all repositories in the batch,
which is misleading. This results in inaccurate audit log messages that do not correctly
reflect the changes made.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[cursor]

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.}

[cursor]

Malformed audit message when triggers are empty

Low Severity

When updated_code_review_triggers is [] and all target repos already have empty triggers, both added and removed are empty sets, so the fallback branch runs. Since new_triggers is also empty, the join produces an empty string, resulting in the malformed audit message " (triggers set to )" with nothing after "to". The serializer allows empty lists (no min_length constraint), so this path is reachable.

 

[cursor]

Old audit log entries render as empty strings

Medium Severity

The template changed from {repository_count} to {repository_names}{code_review_change}, but pre-existing REPO_SETTINGS_EDIT audit log entries in the database only have repository_count in their data dict — they lack repository_names and code_review_change. When AuditLogEvent.render calls template.format(**data) on those old entries, it raises a KeyError. The serializer catches this and falls back to an empty string, so old audit log entries silently lose their rendered message instead of displaying the original text.