kit icon indicating copy to clipboard operation
kit copied to clipboard

Invalidate should invalidate cached server load responses

Open arackaf opened this issue 3 years ago • 2 comments

Describe the bug

Based on the comment here:

https://github.com/sveltejs/kit/issues/6477#issuecomment-1256644295

it would seem like invalidate(identifier) would override cached results from a server load function. I'm having trouble reproducing that, though.

My server file looks like this

let i = 0;

import type { PageServerLoad } from './$types';

// @ts-ignore
export async function load(params) {
	console.log('LOADING');

	// const val = params.url.searchParams.get('val');
	const val = params.url.search;

	const result = {
		searchProps: 'Value ' + val + ' ' + ' CACHE TEST VALUE === ' + i++
	};

	params.setHeaders({
		'cache-control': 'max-age=60'
	});

	params.depends('search:main');

	return result;
}

and my svelte page looks like this, in part

<a href="/?val=A">1</a>
<a href="/?val=B">2</a>
<a href="/?val=C">3</a>

Clicking around those pages does properly cache (check the CACHE TEST VALUE) - but clicking the invalidate button does not seem to work well at all. It seems to usually reload the current page, but other pages remained cached, and what's more, if I navigate back to the page I was on when I clicked invalidate, I get the old cached data, not the new data that was sent the moment I clicked invalidtae. Actually ... clicking invalidate seems to just pull cached data :\

Reproduction

The minimal repro is here: https://github.com/arackaf/booklist/tree/special/bug-repro/svelte-kit

the directory above that has a huge project around it, but that directory I've linked to contains a minimal SvelteKit app that reproduces this (ostensible) bug.

It's deployed here: https://booklist-svelte-kit.vercel.app/

Logs

No response

System Info

System:
    OS: macOS 12.6
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 149.78 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.14.2 - /usr/local/Cellar/nvm/0.38.0/versions/node/v16.14.2/bin/node
    Yarn: 1.22.17 - /usr/local/Cellar/nvm/0.38.0/versions/node/v16.11.1/bin/yarn
    npm: 8.18.0 - ~/Documents/node_modules/.bin/npm
  Browsers:
    Chrome: 107.0.5304.110
    Firefox: 107.0
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.89 
    @sveltejs/kit: next => 1.0.0-next.557 
    svelte: ^3.44.0 => 3.53.1 
    vite: ^3.1.0 => 3.2.4

Severity

blocking all usage of SvelteKit

Additional Information

No response

arackaf avatar Nov 23 '22 17:11 arackaf

Is the request here that invalidate() be able to override the browser's own cache of the responses from endpoints? There's no API for that. Are you imagining this working by automatically adding some sort of cache busting query params to the request URLs?

Conduitry avatar Nov 23 '22 17:11 Conduitry

Honestly not sure how it would work. From Rich's comments in the linked issue, it sounded like maybe there was a client-side ttl being stored. I thought maybe, after invalidation a fetch with a no-cache option might be used on the next data load? Of course that wouldn't help if the user reloaded the page and got a new ttl value sent down, resetting everything.

If this is by design and expected by all means close. I just thought this would be supported.

arackaf avatar Nov 23 '22 17:11 arackaf

The Remix dude was kind enough to chime in with a solution to this!

image

arackaf avatar Nov 23 '22 20:11 arackaf