fix(preprod): Gate comparison download query on SUCCESS state#109923
Merged
NicoHinderling merged 1 commit intomasterfrom Mar 5, 2026
Merged
fix(preprod): Gate comparison download query on SUCCESS state#109923NicoHinderling merged 1 commit intomasterfrom
NicoHinderling merged 1 commit intomasterfrom
Conversation
The comparison data download query fires as soon as metric IDs are available, regardless of whether the async Celery comparison task has completed. When the comparison is still PENDING/PROCESSING, the download endpoint returns 404. React Query caches this error, and when the status poll detects SUCCESS, the stale error is shown instead of fetching the now-available data. Add a state check to the enabled condition so the download query only fires after the comparison is confirmed complete. Co-Authored-By: Claude <noreply@anthropic.com>
github-actions
bot
added
the
Scope: Frontend
rbro112
approved these changes
Mar 5, 2026
NicoHinderling
deleted the
NicoHinderling/fix/size-compare-race-condition
branch
JonasBa
pushed a commit
that referenced
this pull request
Mar 5, 2026
The comparison data download query (`comparisonDataQuery`) fires as soon as metric IDs are available from the status polling query, regardless of whether the async Celery comparison task has actually completed. When the comparison state is still PENDING or PROCESSING, the download endpoint returns 404 because the comparison file hasn't been created yet. React Query exhausts its retries and caches the error. Later, when the status poll detects the transition to SUCCESS, the download query doesn't re-fire because it already has a cached (error) response — resulting in "Comparison not found" being shown to the user. Adds `mainArtifactComparison?.state === SizeAnalysisComparisonState.SUCCESS` to the `enabled` condition of the download query. This ensures the query only fires after the comparison is confirmed complete, at which point the file is guaranteed to exist. The existing 10-second `refetchInterval` on the status query handles detecting the state transition. Reported by customer — the issue reproduced ~50% of the time on initial load but always resolved on page reload (because by then the comparison had completed and the SUCCESS state was returned immediately). Co-authored-by: Claude <noreply@anthropic.com>
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.
The comparison data download query (
comparisonDataQuery) fires as soon as metric IDs are available from the status polling query, regardless of whether the async Celery comparison task has actually completed. When the comparison state is still PENDING or PROCESSING, the download endpoint returns 404 because the comparison file hasn't been created yet. React Query exhausts its retries and caches the error. Later, when the status poll detects the transition to SUCCESS, the download query doesn't re-fire because it already has a cached (error) response — resulting in "Comparison not found" being shown to the user.Adds
mainArtifactComparison?.state === SizeAnalysisComparisonState.SUCCESSto theenabledcondition of the download query. This ensures the query only fires after the comparison is confirmed complete, at which point the file is guaranteed to exist. The existing 10-secondrefetchIntervalon the status query handles detecting the state transition.Reported by customer — the issue reproduced ~50% of the time on initial load but always resolved on page reload (because by then the comparison had completed and the SUCCESS state was returned immediately).