fix(frontend): gate app boot on ConfigStore.hasLoaded to avoid loader deadlock#7776
Open
talissoncosta wants to merge 2 commits into
Open
fix(frontend): gate app boot on ConfigStore.hasLoaded to avoid loader deadlock#7776talissoncosta wants to merge 2 commits into
talissoncosta wants to merge 2 commits into
Conversation
ConfigStore.model is never populated (getAllFlags() returns nothing at the point config-store assigns it), so the provider always started in the loading state even when the store had already finished loading. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The SDK's onChange can fire between the constructor reading the store and componentDidMount subscribing to it. In E2E mode realtime, events and analytics are disabled, so the missed event left the app on the boot loader indefinitely. Re-read the store after subscribing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
github-actions
Bot
added
the
front-end
Contributor
Docker builds report
|
Contributor
Playwright Test Results (oss - depot-ubuntu-latest-arm-16)
Details
Playwright Test Results (oss - depot-ubuntu-latest-16)
Details
Playwright Test Results (private-cloud - depot-ubuntu-latest-arm-16)
Details
Playwright Test Results (private-cloud - depot-ubuntu-latest-16)
Details
|
Contributor
Visual Regression19 screenshots compared. See report for details. |
Zaimwa9
approved these changes
Jun 15, 2026
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
3 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.
Thanks for submitting a PR! Please check the boxes below:
docs/if required so people know about the feature.Changes
Root cause of the intermittent E2E failures blocking the production deploy gate since Jun 9 (see Slack thread). Replaces #7775 (closed; GitHub blocks reopening after a force-push).
Two stacked problems in the app's boot gate:
ConfigProviderdecides whether the app is still loading by checkingConfigStore.model— butmodelis never populated (flagsmith.getAllFlags()returns nothing at the pointconfig-store.jsassigns it; instrumentation showedhasLoaded: true, model: nullwhile the SDK itself held 132 flags). So every mount starts in the loading state regardless of the store's actual state.changeevent, which the provider subscribes to incomponentDidMount. If the SDK'sonChangefires before that subscription (fast edge response + slow runner), the event is lost. In E2E moderealtime,enableEventsandenableAnalyticsare all disabled, so no later event ever arrives and the app sits on the boot loader permanently — tests time out waiting for the login form on a page that never booted. Real users are rescued by realtime/analytics-driven events, which is why this only surfaced in E2E.Fix, one commit each: gate the initial state on
hasLoaded(which is reliably set), and re-read the store after subscribing so an event landing in the constructor→subscription gap cannot strand the boot.How did you test this code?
Deterministic A/B validation by artificially forcing the race (subscription delayed 3s so the SDK's
onChangealways lands in the gap), then loading/loginon 15 fresh browser contexts per build:[name="email"]timeout)modelmodelis never sethasLoaded(this PR)Also reproduced the original hang locally via
environment-permission-test.pw.tsagainst production (the test that failed on every red deploy run — it re-logs in 6+ times, so it rolls the boot race most often).