Background
Two callers independently invoke EditorSettingsRepository.fetchEditorCapabilitiesForSite(site) during MySiteViewModel.refresh() and onResume():
Both fire on every refresh and resume, so on a cold launch both callers race the same fetch.
EditorSettingsRepository.fetchEditorCapabilitiesForSite has no in-flight deduplication — each call fans out two async requests (fetchRouteSupport, fetchThemeBlockStyleSupport) and they all write back to the same appPrefsWrapper keys. So a first-launch refresh issues 4 parallel HTTP requests when one would do, with last-write-wins races on shared prefs.
Mitigating factors
- Both callers have per-session dedup after a successful fetch (
shouldPreload state map in the preloader; fetchedCapabilitiesForSite set in the slice), so the duplicate only happens on the first call per site per session.
- The shared-prefs race is usually benign — both writers write the same value — but it's wasted bandwidth and a small thundering-herd on the WP API for the apiRoot fetch.
Possible fixes
- In-flight dedup at the
EditorSettingsRepository layer (e.g. a per-site Deferred cache that the second caller awaits).
- Have the connectivity slice observe the preloader's result (the preloader is the de-facto driver of editor capabilities; the slice's banner is downstream of whether that fetch succeeded).
- Inverse: have the preloader observe the slice (less natural — the slice exists to react to the fetch, not own it).
Option 2 is the cleanest if the preloader's fetch path can expose a success/failure signal the slice can subscribe to.
Related
Background
Two callers independently invoke
EditorSettingsRepository.fetchEditorCapabilitiesForSite(site)duringMySiteViewModel.refresh()andonResume():GutenbergEditorPreloader.preloadIfNeeded/refreshPreloading— added in Integrate Gutenberg Preloading #22579.SiteConnectivityBannerViewModelSlice.fetchCapabilities— added in Replace site-settings snackbar with My Site connectivity banner #22834.Both fire on every refresh and resume, so on a cold launch both callers race the same fetch.
EditorSettingsRepository.fetchEditorCapabilitiesForSitehas no in-flight deduplication — each call fans out twoasyncrequests (fetchRouteSupport,fetchThemeBlockStyleSupport) and they all write back to the sameappPrefsWrapperkeys. So a first-launch refresh issues 4 parallel HTTP requests when one would do, with last-write-wins races on shared prefs.Mitigating factors
shouldPreloadstate map in the preloader;fetchedCapabilitiesForSiteset in the slice), so the duplicate only happens on the first call per site per session.Possible fixes
EditorSettingsRepositorylayer (e.g. a per-siteDeferredcache that the second caller awaits).Option 2 is the cleanest if the preloader's fetch path can expose a success/failure signal the slice can subscribe to.
Related
GutenbergEditorPreloader)