ResourceLoader: Fix error on querying progress for uncached loads #95476
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #95470.
Discussion:
#93540 did two things: 1) consider cache-ignore-deep in addition to cache-ignore in the relevant logic; 2) isolate uncached loads further than they previously were so they would be truly fresh.
Change 2) is the one at play here. Elaborating, before it, uncached loads would be registered in the map of load tasks only if no other load tasks existed for the same path, Otherwise, the uncached load couldn't be registered so it had to complete synchronously. If that had happened even before #93540, the same bug would have arisen. However, after the PR, which makes the isolation more strict, it's easier to hit the problem.
The underlying issue is precisely that the isolation is implemented by neglecting the map of load tasks for uncached loads (a bit less strictly before #93540, but just as a flawed optimization of the same idea). The proper fix is to redesign the data structures (map of load tasks, maybe load tokens as well) so the isolation can be implemented more cleanly.
Prior to a change as deep as that one we have two issues: 1) uncached loads can't take advantage of other ongoing uncached loads (which may be wanted or not, but the curent implementation prevents it altogether): 2) it's impossible to query progress of an uncached load (before #93540 it was possible in most cases).
My plan, even before this bug, was to work on the proper implementation at some point, and that will still happen. In the current RC stage, the best thing to do is restore the already flawed behavior pre-93540. That boils down to a partial revert of #93540, bringing back the less strict isolation between cached and uncached. That's what this PR does.