feat(autofix): Add pr_iteration endpoint step and operator activity

[joseph-sentry]

Accept the pr_iteration step in the explorer autofix endpoint, gated behind
the autofix-pr-iteration feature flag. The step requires an existing run with
at least one created pull request, otherwise it returns a 400. Map the
SEER_ITERATION_COMPLETED webhook to a SEER_ITERATION_COMPLETED group activity
in the operator, carrying the pull requests and iteration index.

Also, transform user IDs stored in run state feedback into serialized users for frontend

[linear-code]

CW-1399

[Zylphrex]

A few things but overall LGTM

Does this need to be added to the on completion hook as well so it responds in slack and we fire a webhook? Can be in a follow up, just wondering what the plan is.

[Zylphrex]

Just a thought but why not just store the user here and avoid having to hydrate the user later?

This is manual process so my expectations are that this wont take up that much storage anyways

[Zylphrex]

Can you explain what this activity does?

[joseph-sentry]

mostly here for parity with the other steps having activities, but i don't think this ends up doing anything right now

there is code that seems like it'll handle activities in the future, that's behind a feature flag and there's currently no handlers implemented for these activities

there's also an activity log in the UI where we show these, that's behind a feature flag

[cursor]

PR iteration allows non-created PRs

Medium Severity

pr_iteration is only blocked when repo_pr_states is empty, not when every entry lacks a created PR. Runs with only creating or error states still pass validation and return 202, which conflicts with the documented requirement for at least one created pull request.

 

^{Reviewed by Cursor Bugbot for commit 8b754c1. Configure here.}

[sentry]

Bug: The get_iteration_for_insert_index function lacks bounds checking for insert_index and safe access for metadata["iteration_index"], risking unhandled exceptions.
_{Severity: HIGH}

Suggested Fix

Add validation to ensure insert_index is within the bounds of the state.blocks list before access. When retrieving iteration_index from a block's metadata, use the .get() method with a default value or wrap the access in a try...except KeyError block to prevent unhandled exceptions.

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/seer/autofix/autofix_agent.py#L388-L389

Potential issue: In the `pr_iteration` flow, the function
`get_iteration_for_insert_index` uses a user-provided `insert_index` to access
`state.blocks[insert_index]` without performing a bounds check. It also accesses
`metadata["iteration_index"]` without a safe fallback like `.get()`. An out-of-bounds
`insert_index` will raise an `IndexError`, and a missing `iteration_index` key will
raise a `KeyError`. Neither of these exceptions are caught by the endpoint's existing
exception handlers, which will cause an unhandled 500 server error on the public API.

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

[sentry-warden]

Self-serialized user (all emails, options, flags) stored in Seer feedback metadata and returned to other org members

When submitting pr_iteration feedback, the endpoint serializes the requesting user with as_user=serialize_generic_user(request.user). Because as_user equals the target user, UserSerializer._user_is_requester is True and the result is a UserSerializerResponseSelf containing the user's full registered email list, user options, and internal flags. This payload is stored in feedback.source["user"], embedded into the Seer message's prompt_metadata["feedback"], and round-tripped back through block.dict() in the GET endpoint, where any authenticated org member with group-read access can read another member's personal emails, options, and flags. Only a minimal attribution subset (id, name, avatarUrl) is needed.

Evidence

• group_ai_autofix.py:329-331 calls user_service.serialize_many(filter={"user_ids":[request.user.id]}, as_user=serialize_generic_user(request.user)); since as_user is the same user, UserSerializer._user_is_requester returns True.
• users/api/serializers/user.py:193-203 then populates emails (all UserEmail rows), options, and flags, producing UserSerializerResponseSelf rather than the public response.
• The result is stored as feedback.source["user"] (Feedback in autofix_agent.py) and embedded via prompt_metadata["feedback"] = json.dumps({... "source": feedback.source ...}) at autofix_agent.py:418.
• Message.metadata is dict[str, str] | None (agent/client_models.py:33) and is part of MemoryBlock; the GET handler returns blocks = [block.dict() for block in state.blocks] at group_ai_autofix.py:442, surfacing message.metadata.feedback to any org member with group-read access.

Also found at 2 additional locations

• src/sentry/seer/endpoints/group_ai_autofix.py:68-69
• src/sentry/seer/endpoints/group_ai_autofix.py:326-342

_{Identified by Warden wrdn-data-exfil, wrdn-pii · GE3-KTX}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 3 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d36c8a5. Configure here.}

[cursor]

Missing endpoint-level feature flag check for pr_iteration

Medium Severity

The endpoint checks that resolved_run_id is not None for pr_iteration, but never checks features.has("organizations:autofix-pr-iteration", ...) before calling trigger_autofix_agent. The test test_pr_iteration_requires_feature_flag asserts mock_trigger_explorer.assert_not_called() and expects a 403, but since trigger_autofix_agent is mocked (and won't raise PrIterationNotEnabledException), the endpoint proceeds normally and returns 202. An endpoint-level feature flag gate is needed here to match the documented intended behavior.

 

^{Reviewed by Cursor Bugbot for commit d36c8a5. Configure here.}

[sentry]

Bug: The check user_context is not None allows empty strings, creating unnecessary Feedback objects and triggering RPC calls even when no meaningful context is provided.
_{Severity: LOW}

Suggested Fix

Change the condition at line 317 from if user_context is not None to if user_context. This truthy check will correctly filter out empty strings and prevent the creation of meaningless feedback objects.

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/seer/endpoints/group_ai_autofix.py#L317-L321

Potential issue: When a client sends an empty string for `user_context`, the condition
`user_context is not None` evaluates to true. This results in the creation and storage
of a `Feedback` object with an empty message. This behavior leads to several
inefficiencies: an unnecessary RPC call to `user_service.serialize_many()`, storage of
meaningless feedback data in the run's metadata, and a misleading `has_user_context`
metric being set to `"yes"`. The intended behavior, as seen in `build_step_prompt`, is
likely to only process feedback when `user_context` is a non-empty string.