`Could not get the request store` During Server Test

[systemcarl]

Describe the bug

Previously, the sequence() generated handle could be called from a test to simulate request handling. When upgrading to the latest SvelteKit version, this now raises an error: Could not get the request store. This is an internal error. It appears this is due to missing state expected by the new OpenTelemetry Tracing feature.

I am not aware of any other way of directly testing server hooks then by invoking them directly in a test. The only work around I found is by mocking the sequence helper in the test fixture.

Reproduction

This reproduction demonstrates the error:
sveltekit-issue-get-request-store

The repository also includes a working test, using SveltKit v2.21.2.

Logs

FAIL   server  src/hooks.server.test.ts > can call handler
Error: Could not get the request store. This is an internal error.
 ❯ get_request_store node_modules/@sveltejs/kit/src/exports/internal/event.js:48:9
 ❯ node_modules/@sveltejs/kit/src/exports/hooks/sequence.js:85:21
 ❯ src/hooks.server.test.ts:12:26
     10|   } as RequestEvent
     11|   const resolve = vi.fn().mockResolvedValue(new Response('OK'));
     12|   const response = await handle({ event : event, resolve : resolve });
       |                          ^
     13|   expect(response).toBeDefined();
     14| });

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯


 Test Files  1 failed (1)
      Tests  1 failed (1)
   Start at  11:37:10
   Duration  488ms (transform 53ms, setup 0ms, collect 67ms, tests 8ms, environment 0ms, prepare 127ms)

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    Memory: 1.67 GB / 11.70 GB
  Binaries:
    Node: 22.16.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 4.9.2 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 10.9.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (138.0.3351.77)
    Internet Explorer: 11.0.26100.1882
  npmPackages:
    @sveltejs/adapter-auto: ^6.0.0 => 6.0.1
    @sveltejs/kit: ^2.31.1 => 2.21.2
    @sveltejs/vite-plugin-svelte: ^5.0.0 => 5.1.0
    svelte: ^5.0.0 => 5.33.18
    vite: ^6.2.6 => 6.3.5

Severity

annoyance

Additional Information

No response

[elliott-with-the-longest-name-on-github]

While we figure out what we want to do for this specific case, you could probably mock @sveltejs/kit/internal/server to at least get it passing.

The main challenge here is that your test is technically a little broken. As soon as you use any functions requiring getRequestEvent anywhere in your handle pipeline your test will start blowing up even though your code isn't actually buggy. The way I would recommend testing handle hooks is by using Playwright to actually run your server, but I know that's a little heavy handed for some simpler tests. Will get back to you soon.

[rebasecase]

I tried mocking @sveltejs/kit/internal/server, but it doesn’t behave well. I can’t seem to get it to mock properly. I’m not entirely sure why yet, but it looks related to how it imports from events.

One workaround is mocking sequence and replacing it with a mockImplementation (really this should be called reImplementationYouShouldntDoThis() 🙄) but this really sucks.

That said, I think the real solution is, as you say, using Playwright to run the actual server. It might feel like a cop-out, but unit tests here don’t seem particularly valuable? I think a question I regulaly forget to ask myself is "is this a quality test, why am I testing it? What behaviour is this testing" The answer here, for me, is "so I can be sure that handlerA() calls handlerB() and handlerC()", so basically copying the implementation to a test. This is bad. Good tests care about what the system does, not how it does it.

To solve it by mocking, I don't know how. The mocking issue in practice seems to be this:

• Test starts loading
• Test imports ./hooks.server
• hooks.server imports @sveltejs/kit/hooks
• @sveltejs/kit/hooks imports sequence.js
• sequence.js imports @sveltejs/kit/internal/server (the problematic module)
• The module is cached with the real implementation before mocks are applied

Then the mocks run... but why can't I just invalidate the module cache?? [I tried but it did not work]

I'd love an answer to this

[johnathanludwig]

I've also seen this issue when trying to write a unit tests that calls a remote functions like a query/form.

I could get past this error with a mock. With each mock there is a new error from the internals with each mock, such as with_request_store, transports, and other aspects of state.

It would be nice if there was some easier/recommended way to write unit tests. Playwright is definitely a better test, but then you have to setup so much more of your app and it takes longer so it's not ideal for all tests.

This is what I tried. Something like this dummy event is what I was using for loaders/action unit tests before.

const dummy_event = vi.hoisted(() => {
	return {
		cookies: {
			set: vi.fn(),
			get: vi.fn(),
			getAll: vi.fn(),
			delete: vi.fn(),
			serialize: vi.fn(),
		} satisfies RequestEvent['cookies'],
		request: new Request('http://localhost', {
			method: 'POST',
		}),
		locals: {},
		url: new URL('http://localhost'),
	};
});


vi.mock('@sveltejs/kit/internal/server', () => ({
	get_request_store: () => {
		return {
			request: dummy_event.request,
			event: dummy_event,
			state: {},
		};
	},
	getRequestEvent: () => {
		return dummy_event;
	},
}))

[elliott-with-the-longest-name-on-github]

We've been discussing this internally and I think the real solution here is going to be for us to provide something like withRequestEvent exported from @sveltejs/kit/tests for testing -- you'd use it like this:

test('it works', withRequestEvent({ ...event details... }, () => {
  // your code relying on SvelteKit internals
}))

The core problem is that most of the SvelteKit internals rely on AsyncLocalStorage so that you can use things like getRequestEvent in functions without having to drill event down through all of your layers of functions calls, and in order to unit test things running inside the SvelteKit runtime you need to have a way to mock that ALS store. We're still trying to find the balance here, so stay tuned. Not sure exactly when we'd come out with something like this.

That being said, we've found a way to make sequence not rely on any of that ALS stuff so after I get a PR up it'll continue to work in unit tests... for now 😆 Note that it'll still be "buggy" in the same way it was before -- none of your code using getRequestEvent will work inside.

[rebasecase]

That is incredible thank you