Not recovering from failed dynamic import

[cwalten]

This issue arises when a dynamic import fails (in this case due to network instability). If the request does fail, the import code will never attempt to request the CSS again. Thus, we will never successfully complete the import. The code which is making that request would be something like the following:

import(
  /* webpackChunkName: "AsyncBundle1", webpackMode: "lazy" */
  './AsyncBundle1'
)
.then(AsyncBundle1 => {
  this.AsyncBundle1 = AsyncBundle1.default;
})
.catch((error) => {
  console.log(error);
})

Sorry I could not provide a better base example, as this issue requires a server and network manipulation to achieve.

Reproduction steps:

1. The bundle is requested and the network call fails.
2. The CSS request Promise is rejected here, but the bundle's key in installedCssChunks is not cleared.
3. We retry the request, but this line is executed, placing the rejected Promise in the promises array, not a new Promise.
4. This will evaluate to Rejected every time, never even making a second service request for that CSS.

This shows that the installedCssChunks has held onto the Rejected Promise:

This shows that the CSS was never requested again, failing the Promise in the example above (Note: the blank row is a JSON request not relevant for this discussion):

This shows the Rejected Promise being pushed into the promises array for 'execution' (immediate rejection):

It is possible I have implemented this dynamic request incorrectly, but I was unable to find any solutions which fixed this issue through Webpack or this plugin specifically. Since the Javascript is being requested successfully (see above), it feels like an issue with the template code provided by this plugin.

[cwalten]

After some further research, it looks like the code which reloads the Javascript files also adds another set of script tags when it retries (duplicating the script tags in the DOM). Currently, this plugin does not do this for its link tags due to this line.

This seems to be the cause for the css not being re-requested, even if we clear the chunkId from installedCssChunks. I am currently working on an implementation to fix this for PR, though I would welcome preemptive feedback on the consequences of these proposed changes.

[alexander-akait]

@cwalten PR welcome

[vtenfys]

Hi @evilebottnawi - I'm currently working on the GatsbyJS offline plugin, and noticed that this problem is preventing page resources from loading after going offline and then regaining connection.

I saw there's currently an open PR to fix this (#292) - is there any reason why this hasn't been merged yet? We would love to get this fixed so I'd be happy to continue working on the PR if there's anything that needs changing!

[alexander-akait]

@davidbailey00 need review from @sokra , i sent request on review again

[alexander-akait]

@cwalten problem solved in #292? We can close?

[cwalten]

Looks good, thanks for your help!