${node.server_id}: Calling `depends(...)` in a promise handl

Error message

${node.server_id}: Calling `depends(...)` in a promise handler after `load(...)` has returned will not cause the function to re-run when the dependency is invalidated

What it means

`depends(...)` declares a custom invalidation dependency for a `load` function. Calling it in a promise handler after `load` has returned means the dependency is registered too late (and here triggers a warning when the href was not already tracked), so invalidating that dependency will not re-run `load`.

Source

Thrown at packages/kit/src/runtime/server/page/load_data.js:108

						if (DEV && done && !uses.dependencies.has(url.href)) {
							console.warn(
								`${node.server_id}: Calling \`event.fetch(...)\` in a promise handler after \`load(...)\` has returned will not cause the function to re-run when the dependency is invalidated`
							);
						}

						// Note: server fetches are not added to uses.depends due to security concerns
						return event.fetch(info, init);
					},
					/** @param {string[]} deps */
					depends: (...deps) => {
						for (const dep of deps) {
							const { href } = new URL(dep, event.url);

							if (DEV) {
								validate_depends(node.server_id || 'missing route ID', dep);

								if (done && !uses.dependencies.has(href)) {
									console.warn(
										`${node.server_id}: Calling \`depends(...)\` in a promise handler after \`load(...)\` has returned will not cause the function to re-run when the dependency is invalidated`
									);
								}
							}

							uses.dependencies.add(href);
						}
					},
					params: new Proxy(event.params, {
						get: (target, key) => {
							if (DEV && done && typeof key === 'string' && !uses.params.has(key)) {
								console.warn(
									`${node.server_id}: Accessing \`params.${String(
										key
									)}\` in a promise handler after \`load(...)\` has returned will not cause the function to re-run when the param changes`
								);
							}

View on GitHub (pinned to 03f1687fe6)

Solutions

Call `depends()` synchronously at the start of `load`, before any `await`.
Declare every custom dependency up front even if the related data is fetched later.
Move the deferred logic so dependency registration and data fetch happen together within the load body.

Example fix

// before
export function load({ depends }) {
  return getData().then((d) => { depends('app:data'); return d; });
}
// after
export async function load({ depends }) {
  depends('app:data');
  const d = await getData();
  return { d };
}

Defensive patterns

Strategy: validation

Validate before calling

export async function load({ depends }) {
  depends('app:data'); // register all custom deps first, unconditionally
  const data = await getData();
  return { data };
}

Prevention

Call `depends()` at the very top of `load`, before any `await`.
List every custom dependency explicitly rather than conditionally in async code.
Review load functions after refactors to ensure depends calls did not drift into callbacks.

When it happens

Trigger: Server `load` calls `depends('app:x', ...)` inside a `.then()`/post-await continuation after the body finished (`done === true`) and `app:x` (resolved href) is not in `uses.dependencies`.

Common situations: Registering custom dependencies after awaiting data; conditional `depends` calls in async callbacks that resolve post-return.

Related errors

AI-assisted analysis of sveltejs/kit@03f1687fe6 (2026-09-02). Data as JSON: /api/errors/dfe6db0c4db6004f. Report an issue: GitHub.