Why does audio loading failure in HTML5 still resolve the Future with onComplete?

Hi,
I have a question regarding how audio loading errors are handled in HTML5 builds in OpenFL.

When an audio file fails to load (e.g., 404 or CORS issue), the Future still completes successfully via onComplete, and onError is never called. From the source, I can see this is intentional — the loadAudioBuffer_onError fallback just logs a warning and continues with an empty AudioBuffer:

@:noCompletion private function loadAudioBuffer_onError(id:String, message:Dynamic):Void {
	#if (js && html5)
	if (message != null && message != "") {
		Log.warn("Could not load \"" + id + "\": " + Std.string(message));
	} else {
		Log.warn("Could not load \"" + id + "\"");
	}
	loadAudioBuffer_onComplete(id, new AudioBuffer()); // fallback
	#else
	load_onError(id, message);
	#end
}

So the question is — why was it designed this way?
Was the idea to avoid breaking the app flow due to missing sounds, or is it a workaround for limitations in the Web Audio API or browser behavior?

Either way, this makes it harder to distinguish between successful and failed loads when using Future, unless we add our own checks.

Would appreciate any insight from the maintainers or those familiar with this part of the codebase. Thanks!

I was not involved with the project at the time, so I am unsure why it was designed this way. It seems wrong to me too, though.

Unfortunately, there is no further explanation, nor any reference to an issue, in the commit where this was added to Lime 6.3.0:

It appears that it affects audio from the asset library preloaded on startup only, and if you were to load the audio on demand after startup, I would expect a proper error to be reported, so at least there’s a potential workaround available.