archives

« Bugzilla Issues Index

#2994 — 15.2.4.7.1 AsyncStartLoadPartwayThrough shouldn't throw for existing load records


I assume step 6 is supposed to read loader.[[Loads]] not loader.[[Modules]] otherwise this is a duplicate check.

But if we import a dependency while it is already an existing load record for the loader (say as a dependency of another load), we should be picking up from that load record and not throwing in this situation.


Note I have implemented a fix that allows GetOrCreateLoad to be used more widely to solve this, as well as https://bugs.ecmascript.org/show_bug.cgi?id=2601.

It does involve adding two new load record states, "init" and "completed", and some other adjustments to the algorithm, but I think having a complete GetOrCreateLoad implementation could be useful to handle these kinds of scenarios generally.

I'd be happy to write out these changes in spec language if it would help.


To summarize the issue in case it isn't clear:

System.import('A')
setTimeout(function() {
System.import('B')
});

A depends on B.

If we manage to get the timing right to import B while it has a load record for A that is not yet loaded, the load for B will throw.


Another side effect of this, in combination with https://bugs.ecmascript.org/show_bug.cgi?id=3097.

When a load fails, and we try to load a module that depends on non-failing dependencies of that failed load, we get an error.

System.import('foo') // fails on loading dependency "bar"

Where foo depends on "bar" and "baz", and "bar" is a failing load record.

If I later import baz:

System.import('baz')
// throws since baz already loading


(In reply to Guy Bedford from comment #1)
> Note I have implemented a fix that allows GetOrCreateLoad to be used more
> widely to solve this, as well as
> https://bugs.ecmascript.org/show_bug.cgi?id=2601.
>
> It does involve adding two new load record states, "init" and "completed",
> and some other adjustments to the algorithm, but I think having a complete
> GetOrCreateLoad implementation could be useful to handle these kinds of
> scenarios generally.
>
> I'd be happy to write out these changes in spec language if it would help.

Sorry it's been a while, I'm just getting to update the module load algorithms in the spec.

It would be great if you could write up you fix for this. It doesn't have to be anything fancy, just a the basic algorithm out line. I'll do the necessary reformatting.


(In reply to Allen Wirfs-Brock from comment #4)
>
> It would be great if you could write up you fix for this. It doesn't have
> to be anything fancy, just a the basic algorithm out line. I'll do the
> necessary reformatting.

Don't bother, I've already taken care of this.


concerns old module spec.