SSR should fail if `setContext` is used after an `await`

[Rich-Harris]

Describe the bug

Code like this...

<script>
	import { setContext } from 'svelte';

	await Promise.resolve('hi');

	setContext('key', 'value');
</script>

...fails in CSR, because we need to set context before doing any out-of-order rendering. But it doesn't fail in SSR. It should. The relevant test is currently skipped: https://github.com/sveltejs/svelte/pull/17154/files#r2558303462

Reproduction

playground

Logs

System Info

latest

Severity

annoyance

[einarpersson]

As someone who does not know the internals of svelte, i have to admit that it is not at all evident why something like this should fail.

If there are more of these "special (async?) rules" perhaps they could/should be listed and explained somewhere in the docs. And the language tools have to be helpful for all these kinds of cases.

[sirkostya009]

it'd actually be great if you could set context even after an async operation, i had hoped something like this would work in my code:

<script>
    const value = setContext('key', await import('$lib/module.js'));
</script>

[Rich-Harris]

Consider a case like this:

<script>
  import ComponentThatDoesAsyncWork from './ComponentThatDoesAsyncWork.svelte';

  const foo = await someSlowOperation();
</script>

<p>foo: {foo}</p>
<ComponentThatDoesAsyncWork />

It's essential that <ComponentThatDoesAsyncWork> renders as soon as it can, so that its async work isn't blocked on foo. Because of that, Svelte renders things out of order.

It's able to do that because it can see that <ComponentThatDoesAsyncWork> doesn't depend on foo. But it can't see whether or not it depends on context. Because of that, it's necessary to set context synchronously, so that's guaranteed to be present before getContext(...) is called.