Is a Global Retry Policy Needed for Babylon.js Asset Loading?

Is a Global Retry Policy Needed?

Yes, if your application requires resilience against transient network failures, you must implement your own global retry policy. Babylon.js does not provide a built-in global configuration to automatically retry failed asset loads across a scene.

Current Behavior and Limitations

In Babylon.js v5 and later, the SceneLoader operates with the following constraints:

• Default Retry Count: The default retry count is zero. If a request fails, the loader immediately emits an error event and stops.
• Lack of Backoff: Even when a retry option is passed to an individual load call, the engine performs immediate retries. There is no native support for configurable delays or exponential backoff.
• Version Sensitivity: While retry options existed in v4.x, the refactoring in v5.0 shifted the responsibility of failure recovery more heavily toward the developer.

Recommended Implementation

Since there is no global setting, the most effective way to enforce a consistent policy is to create a wrapper function around SceneLoader.ImportMesh or SceneLoader.Append. This allows you to inject custom delay logic (backoff) that the native retry option lacks.

async function loadAssetWithRetry(scene, url, meshNames, sceneName, options = {}, maxRetries = 3, delayMs = 1000) {
    let attempt = 0;
    while (attempt < maxRetries) {
        try {
            return await BABYLON.SceneLoader.ImportMeshAsync(meshNames, url, sceneName, scene, options);
        } catch (error) {
            attempt++;
            if (attempt === maxRetries) throw error;
            // Implement simple linear backoff
            await new Promise(resolve => setTimeout(resolve, delayMs * attempt));
        }
    }
}

Verification Steps

1. Test Failure: Attempt to load a non-existent asset URL without a wrapper to confirm that only one network request is made.
2. Verify Timing: Use the Browser Network tab to ensure that retries are not happening instantaneously, which would indicate the native retry option is being used instead of a custom backoff wrapper.

Diagnostic Detail Needed: Are you loading assets from a CDN with strict rate-limiting? If so, a linear backoff may be insufficient, and a true exponential backoff strategy should be implemented in the wrapper.