fix(dashboard): prevent duplicate screenshot downloads#39525
fix(dashboard): prevent duplicate screenshot downloads#39525
Conversation
Add isFetching / isDownloaded guards in useDownloadScreenshot so concurrent poll requests cannot each resolve with 200 and trigger multiple a.click() downloads. Regression surfaced by #38880 which forced async regeneration on every download, making the retry path the default and exposing the pre-existing race. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Code Review Agent Run #5bced2Actionable Suggestions - 0Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help AI Code Review powered by |
dosubot
Bot
added
change:frontend
|
|
||
| test('downloadScreenshot calls API with force=true to ensure fresh screenshots', async () => { | ||
| const mockCacheKey = 'test-cache-key'; | ||
| const RETRY_INTERVAL = 3000; |
There was a problem hiding this comment.
Do we have this somewhere else as well that we can use?
|
The PR only modifies the test file for the useDownloadScreenshot hook. It doesn't show usage of the hook elsewhere in the codebase. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #39525 +/- ##
==========================================
+ Coverage 64.46% 64.50% +0.04%
==========================================
Files 2559 2559
Lines 133564 133641 +77
Branches 31016 31049 +33
==========================================
+ Hits 86097 86207 +110
+ Misses 45974 45941 -33
Partials 1493 1493
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
2 participants
SUMMARY
Fixes a race condition in
useDownloadScreenshotwhere some users saw the dashboard screenshot (PDF/PNG) downloaded twice when triggered via the browser. The polling loop that waits for the generated screenshot had no in-flight guard, so interval ticks could stack concurrent GETs; when the image became ready, each in-flight request returned 200 and each triggereda.click().Why it started happening recently — the polling logic was pre-existing, but #38880 (
fix(dashboard): Ensure screenshot downloads always generate fresh images/pdfs) addedforce=trueto the cache_dashboard_screenshot POST. Before, the backend could serve a cached screenshot immediately and no retries were needed. After, the async Celery task runs on every download, so the retry path is now the default, exposing the race on every request.The fix — two guards in
downloadScreenshot(both local to one invocation):isFetching—fetchImageWithRetryshort-circuits while a GET is still pending, so interval ticks can't stack concurrent requests. Reset in.finally.isDownloaded— the success.thenbails if already downloaded, and sets the flag + callsstopIntervals('success')beforea.click()so any late-arriving 200 can't fire a second download.BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A — network-level behavior. Reported pattern: multiple 200 responses for
/screenshot/<cache_key>/?download_format=pdfeach triggering a browser download.TESTING INSTRUCTIONS
Unit tests added in
useDownloadScreenshot.test.ts:does not issue overlapping GETs while a previous GET is in-flight— verifies theisFetchingguard by advancing fake timers while the first GET is pending.triggers only one download when multiple successful responses race— verifies only onea.click()fires even when subsequent responses resolve 200.Both tests fail against the current master behavior (click called 5× without the fix) and pass with the fix applied.
Manual: open a large dashboard → Download → PDF/PNG. Confirm exactly one file is downloaded on slow-generation paths.
ADDITIONAL INFORMATION