fix: invalidate parent load functions#11819
fix: invalidate parent load functions#11819gterras wants to merge 1 commit intosveltejs:mainfrom gterras:fix_invalidation_desync
Conversation
|
|
I've tested this and can confirm that it fixes issue #11696 |
dummdidumm
left a comment
dummdidumm
left a comment
There was a problem hiding this comment.
Thanks for making a start at this - though I'm not sure if this looks correct yet. In general the whole "when things are invalidated / reset" is hella hard to figure out. I have to think this through next week.
|
|
||
| for (const href of uses.dependencies) { | ||
| if (invalidated.some((fn) => fn(new URL(href)))) return true; | ||
| if (!parent_changed) { |
There was a problem hiding this comment.
Why would this logic only run if the parent hasn't changed? Wouldn't this result in false negatives?
There was a problem hiding this comment.
What I understand of the whole thing is that every "parent routes" needs to go through the whole invalidation loop else their version of data is not updated. The logic in the file starts with the current page, then up a level until there is none.
The fix in #11268 would strictly break this loop after first iteration, so parents are never actually loaded.
Having !parent_changed there is a mean to ensure this is not the first iteration of the loop (meaning it's a parent), so it's data isn't actually marked for invalidation / invalidated (no need) but every routes still go through a invalidation process (so they get the updated data).
So basically there is a invalidation process that do several things (invalidate the data and assign this data to the route being invalidated), and every segment of the page need to go through this process to receive the proper data, but only the current page segment have to actually invalidate data.
If you prevent parent segments from going into this loop they never get the updated data.
| } | ||
| } | ||
|
|
||
| invalidated.length = 0; |
There was a problem hiding this comment.
Most likely, I see tests failing in the PR but can't find a useful error
There was a problem hiding this comment.
It looks like #11268 did not fix issue #10677 completely. Walking through the instructions in https://github.com/davideaster/sveltekit-invalidations I can still reproduce the error in the last step on the latest commit of sveltekit.
However, when I check out this PR, I can confirm that it brings back the first error from the reproduction repo I've linked above. The PR fixed that first error (invalidate on a non-depends resource following invalidate with depends).
Thanks for answering 🙏 Yes it really seems to be a tough topic and really hard to tackle without additional tests, I can try to add failing ones if you need it. This one especially
Starting from this one could be a softer approach since it's simpler but have similar roots. |
That would be a huge help. I'm on vacation for the next week, so unfortunately not likely to make progress on this personally in the short-term. Tests would help expedite things so that some progress is made in the meantime |
|
Found the culprit, closing in favor of #11870 - thank you for assembling that list of issues! Will go through that to see if that fix also fixes one of the other ones. |
4 participants
Fixes: #11696
also probably
#11635
#11663
#11446
#10209
#10123
#10457
#10359
#11745
See context: #11268 (comment)
Most likely #11268 introduced this behavior that is a blocker preventing an upgrade to SvelteKit2 for any project using "parent invalidation".
Draft status as it needs 2 tests:
I would like to dig into the tests but could someone confirm this PR is on the right tracks?
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.Edits