feat(autofix): make FE changes to match github mentions#118261
Draft
joseph-sentry wants to merge 23 commits into
Draft
feat(autofix): make FE changes to match github mentions#118261joseph-sentry wants to merge 23 commits into
joseph-sentry wants to merge 23 commits into
Conversation
joseph-sentry
commented
Jun 23, 2026
joseph-sentry
commented
Contributor
- update feedback section in code changes card to reflect feedback queueing status:
- we made a change to queue feedback that's received while the autofix agent is already running to avoid concurrency issues, and we want to update the feedback section to reflect this change by showing feedback in 3 different statuses
- processed
- processing
- queued
- we made a change to queue feedback that's received while the autofix agent is already running to avoid concurrency issues, and we want to update the feedback section to reflect this change by showing feedback in 3 different statuses
- poll autofix state when autofix drawer is open, a PR has been created and PR iteration is enabled
- Before, we polled for autofix state while the autofix run was processing
- now, since we can receive feedback from github we need to poll while:
- a PR is created for this run
- PR iteration as a feature is enabled
- the drawer is open
- if we don't do this, then a user in the UI won't be able to see in real time that feedback has come in from Github
This is just adding some UI stuff and fleshing out @alexsohn1126's PR to support ingesting PR iteration feedback through github webhooks the approach is to add a legacy github webhook handler for issue comments then parse it to make sure: - the user is not requesting a review - the user has github write access to the repo then then handler queues up a taskworker task, that task triggers the seer autofix agent with an iteration
this is a case that got brought up after the first iteration of this PR we need to handle the case where we receive comments while an agent.run is under way for a given autofix run before this change we risked a state where we have 2 agent.run happening at the same time writing to the same blocks, this wouldn't mess up the agent runs while they're happening, but the resulting conversation would end up broken and any subsequent iteration would be looking at a weird state of the conversation we want to serialize PR iteration runs so we don't run into the above, we'll do this by queueing feedback that we receive during runs into redis, then at the completion hook after the run is finished we'll queue up another run with the feedback that was buffered the implementation is: - a task that checks whether a run is processing and queues up the feedback if not - a queue of feedback items in redis - writing feedback items when we receive a PR iteration request from the UI or github and running the task - running the task from the completion hook after a PR iteration we avoid: - double work: by having the task be under a redis lock - dropped work: by having the completion hook run the task an important part of this change is the seer behaviour: - seer sets the run state to processing in the endpoint that the task calls synchronously so as far as we can tell, it's being done under the lock so there's no chance of the next task run seeing status != processing when it enters the mutex zone - seer also sets the completed status before calling the completion hook, this eliminates the possibility of dropping work, since we know that the completion hook will _always_ pick up any buffered work that was enqueued during its run
2 changes:
- updating feedback section in code changes card to reflect feedback queueing status
we made a change to queue feedback that's received while the autofix agent is already
running to avoid concurrency issues, and we want to update the feedback section to
reflect this change by showing feedback in 3 different statuses:
- processed
- processing
- queued
- updating polling logic for autofix to catch updates to feedback
in order to accomplish the above, we need to poll autofix state whenever more often
since before we were only polling between the time the user had input something in the UI
and the time seer had said the action associated with that input was completed
now we also want to poll when we have an open PR since github feedback might come in whenever
and we want to reflect the feedback coming in from github in a timely manner
we also want to make sure we're showing that feedback that gets submitted during a run gets queued
up instead of added to the current iteration
github-actions
Bot
added
Scope: Frontend
Contributor
|
🚨 Warning: This pull request contains Frontend and Backend changes! It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently. Have questions? Please ask in the |
Contributor
Backend Test FailuresFailures on
|
![sentry-warden[bot]](https://avatars.githubusercontent.com/in/2755838?s=60&v=4){kind=small}
Route pr_iteration feedback through the match arm so the repo_pr_states check runs before enqueuing, instead of an early return that bypassed it. Update endpoint and webhook tests for the new flow.
When consuming queued feedback, skip github comments already processed into the run's blocks and collapse duplicate comment ids within the batch, so webhook redelivery or task retries can't double-deliver feedback (Warden 2W4-L4C). Dedup keys on the seer run state, the source of truth, so there's no dual-write crash window.
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
2 participants
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.