Failed to get manifest.

• Error Code: RUNTIME-003

#Reasons

Failed to load the manifest, which can occur due to:

1. The manifest URL may be wrong or unreachable
2. Network connectivity issues
3. CORS (Cross-Origin Resource Sharing) restrictions
4. Remote service is offline or not yet deployed
5. DNS resolution failures

#Solutions

#Basic Troubleshooting

1. Check whether manifestUrl can be accessed directly in browser
2. Verify the manifest URL format and path correctness
3. Check network connectivity and DNS resolution
4. Review CORS configuration on the remote server

#Advanced Solutions

#1. Implement Error Handling with Runtime Plugins

Use the errorLoadRemote hook to handle manifest loading failures gracefully:

import type { ModuleFederationRuntimePlugin } from '@module-federation/enhanced/runtime';  const offlineHandlingPlugin: () => ModuleFederationRuntimePlugin = () => ({  name: 'offline-handling-plugin',  errorLoadRemote(args) {  const { lifecycle, id, error } = args;    // Handle different error scenarios based on lifecycle stage  if (lifecycle === 'afterResolve') {  // Manifest loading failure during normal remote loading  console.warn(`Failed to load manifest for remote ${id}:`, error);  // Provide fallback manifest or backup URL  return {  id: 'fallback',  name: 'fallback',  metaData: { /* fallback configuration */ },  shared: [],  remotes: [],  exposes: []  };  }    if (lifecycle === 'beforeLoadShare') {  // Remote loading failure during version-first initialization  console.warn(`Remote ${id} is offline during startup (version-first):`, error);  // Return mock RemoteEntryExports to allow app to continue  return {  init: () => Promise.resolve(),  get: (moduleName) => () => Promise.resolve(() => 'Fallback Component')  };  }  }, });

#2. Use Retry Plugin

Add automatic retry mechanism for transient network failures:

import { RetryPlugin } from '@module-federation/retry-plugin';  // In your Module Federation configuration runtimePlugins: [  () => RetryPlugin({  fetch: {  retryTimes: 3,  retryDelay: 1000,  },  }), ],

#3. Environment-Specific Handling

For different environments, consider:

• Development: Log detailed error information
• Production: Provide graceful fallbacks without exposing internal errors
• Staging: Use backup servers or cached manifests

#ShareStrategy Impact

The shareStrategy affects when manifest loading occurs:

• shareStrategy: 'version-first' - Triggers manifest loading during application initialization for all remotes. Offline remotes will cause startup failures.
• shareStrategy: 'loaded-first' - Defers manifest loading until remotes are actually used. Offline remotes only cause failures when accessing those specific remotes.

For resilience against offline remotes, consider using 'loaded-first' strategy combined with proper error handling.