fix(studio): stop onboarding detect-site refetch loop on failed detection#36
fix(studio): stop onboarding detect-site refetch loop on failed detection#36bnz183 wants to merge 1 commit into
Conversation
…tion The detect-site effect keyed its guard on `report === null`, which conflated "not fetched yet" with "fetched and failed", so a failed/empty detection re-armed the effect and refetched /api/setup/detect in a tight loop. Track the attempted state via a resolved-attempt token (set only when a fetch settles), derive loading/error/loaded status, surface a real error state with a Retry control, and block Continue on failure. Add e2e coverage asserting no refetch loop and single-request retry recovery. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a376feb673
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| (detectionStatus === "loading" || | ||
| detectionStatus === "error" || | ||
| (report !== null && !report.primary))) |
There was a problem hiding this comment.
Block continuing after a null post-save refresh
If the initial scan succeeds but the follow-up fetchSetupDetection() in handleApplySettings returns null after saving settings, detectionError is never set and resolvedAttempt still matches retryCount, so the wizard is in a loaded/null state. This disabled check treats report === null as okay, leaving Continue enabled and allowing users to advance into blank confirmation steps with no active suggestion; please either preserve the previous report or treat this null refresh as an error/blocked state.
Useful? React with 👍 / 👎.
What
The onboarding wizard's
detect-sitestep refetched/api/setup/detectin a tight loop whenever detection failed or returned nothing — ~1,600 requests in 3s, verified at runtime. React's dev-only passive-effect loop guard is stripped in production, so prod silently hammers the API rather than crashing.Root cause
The effect keyed its guard on
report === null, which conflated "not fetched yet" with "fetched and failed". On a null resultreportstayed null whilesetLoadingDetection(false)flipped a dependency, re-running the effect → guard passed → refetch, forever.Fix (
OnboardingWizard.tsxonly)resolvedAttempttoken, set only when a fetch settles (success or failure). The guardresolvedAttempt === retryCountthen stops re-fetching —nullno longer doubles as "unattempted".[step, retryCount, resolvedAttempt]— no self-referentialreport/error outputs, so the effect can't re-arm itself.loadingis derived (avoidsreact-hooks/set-state-in-effect); cleanupignoreflag drops stale/duplicate responses.loading/error, closing the old "click through a blank wizard" hole.Tests
New
e2e/onboarding-detection-loop.spec.ts:Existing happy-path detection test (
smoke.spec.ts) still green.tsc -b+ targeted lint clean; no new lint suppressions.Scope
Touches only
OnboardingWizard.tsxand the new spec. The five other review findings on this branch are intentionally left untouched.🤖 Generated with Claude Code