The Retry Plugin provides a robust retry mechanism for Module Federation. When remote modules or resources fail to load, it retries automatically to keep your app stable.
The plugin configuration has been simplified. The old fetch and script configuration objects are deprecated:
retryTimes
numberretryDelay
numberdomains
string[]addQuery
boolean | ((context: { times: number; originalQuery: string }) => string)fetchOptions
RequestInitmanifestDomains
string[]mf-manifest.json). Takes precedence over domains for manifest fetch retries. Other resources still use domains.onRetry
({ times, domains, url, tagName }: { times?: number; domains?: string[]; url?: string; tagName?: string }) => voidtimes current retry number, domains domain list, url request URL, tagName resource typeonSuccess
({ domains, url, tagName }: { domains?: string[]; url?: string; tagName?: string; }) => voiddomains domain list, url request URL, tagName resource typeonError
({ domains, url, tagName }: { domains?: string[]; url?: string; tagName?: string; }) => voiddomains domain list, url request URL, tagName resource typeThe plugin retries automatically when a resource fails to load. The number of retries is controlled by retryTimes. For example:
retryTimes: 3 means up to 3 retries (after the first attempt)retryDelay ms is applied before each retryWhen domains is configured, the plugin rotates the host on each retry:
Order of attempts:
cdn2.example.comcdn3.example.comcdn1.example.comUse addQuery to add query parameters during retries to avoid cache interference:
You can also provide a function:
You can monitor the retry lifecycle with callbacks:
Callback params:
times: current retry count (starts from 1)domains: the current domain listurl: current request URLtagName: resource type ('fetch' or 'script')domains serve the same resourceaddQuery is enabled, consider CDN caching strategyRUNTIME_008: Resource load failure that triggers the retry mechanism