Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(autofix): Poll for PR state #88832

Merged
merged 1 commit into from
Apr 7, 2025
Merged

fix(autofix): Poll for PR state #88832

merged 1 commit into from
Apr 7, 2025

Conversation

roaga
Copy link
Member

@roaga roaga commented Apr 4, 2025

When creating a branch/PR, we now poll for the state instead of waiting for an API response. This should be more reliable.

@roaga roaga requested a review from a team as a code owner April 4, 2025 18:53
@github-actions github-actions bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Apr 4, 2025
Copy link

codecov bot commented Apr 4, 2025

❌ 1 Tests Failed:

Tests completed Failed Passed Skipped
10116 1 10115 5
View the top 1 failed test(s) by shortest run time
spansWidgetQueries triggers a preflight and then a best effort request
Stack Traces | 0.07s run time
Error: expect(element).toBeInTheDocument()

element could not be found in the document
    at Object.<anonymous> (.../dashboards/widgetCard/spansWidgetQueries.spec.tsx:259:63)

To view more test analytics, go to the Test Analytics Dashboard
📋 Got 3 mins? Take this short survey to help us improve Test Analytics.

@roaga roaga requested a review from jennmueng April 4, 2025 21:27
Comment on lines +181 to +182
const [isPrProcessing, setIsPrProcessing] = useState(false);
const [isBranchProcessing, setIsBranchProcessing] = useState(false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we make these conditions completely reliant on the autofix state instead of being react state? We can just rely on the changes step being in processing status right? Will make all this logic much simpler

If on the seer side we update the status before we return the call then the query invalidation inside onSuccess should already receive a processing state next time it makes a request

@@ -99,7 +99,7 @@ export function useSelectSolution({groupId, runId}: {groupId: string; runId: str
};
}
);
addSuccessMessage("Great, let's move forward with this solution.");
addSuccessMessage('On it.');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i like, much simpler

@roaga roaga merged commit 9c15d1e into master Apr 7, 2025
42 checks passed
@roaga roaga deleted the autofix/new-pr-button branch April 7, 2025 16:55
andrewshie-sentry pushed a commit that referenced this pull request Apr 8, 2025
When creating a branch/PR, we now poll for the state instead of waiting
for an API response. This should be more reliable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Scope: Frontend Automatically applied to PRs that change frontend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants