fix(client-next): build URL after request interceptors

[jnsdls]

Summary

Fixes #3803.

@hey-api/client-next built the request URL before request interceptors ran. That meant request interceptors could mutate opts.baseUrl, opts.url, opts.path, or opts.query, but the fetch call still used the URL that had already been computed from the original options.

This PR moves buildUrl(opts) to after the request interceptor loop so the final fetch URL reflects interceptor mutations. The SSE path keeps the same behavior by seeding createSseClient with the initial URL while still allowing its internal onRequest hook to apply per-request interceptor mutations.

This is specific to client-next: other clients that pass Request objects through interceptors do not need this recomputation step.

Changes

• Defer buildUrl(opts) in packages/openapi-ts/src/plugins/@hey-api/client-next/bundle/client.ts until after request interceptors run.
• Add regression coverage for request interceptor mutations to baseUrl, url, path, and query.
• Refresh generated @hey-api/client-next snapshots, including the SSE Next.js fixture.
• Add a patch changeset for @hey-api/openapi-ts.

Test plan

• pnpm vitest run packages/openapi-ts/src/plugins/@hey-api/client-next/__tests__/client.test.ts
• pnpm vitest run --project @test/openapi-ts packages/openapi-ts-tests/main/test/clients.test.ts -t '@hey-api/client-next'
• pnpm vitest run --project @test/openapi-ts packages/openapi-ts-tests/main/test/3.1.x.test.ts -t 'client with SSE (Next.js)'

[mrlubos]

@jnsdls the error interceptor fix landed as part of #3814, would you be able to apply your changes on main?

[jnsdls]

Thanks for the heads-up. I refreshed the branch onto current main and removed the error-interceptor portion that landed in #3814.

This PR now only contains the @hey-api/client-next URL construction fix, its focused regression tests, the generated client-next snapshots, and the simplified changeset.

Verified locally with:

• pnpm vitest run packages/openapi-ts/src/plugins/@hey-api/client-next/__tests__/client.test.ts
• pnpm vitest run --project @test/openapi-ts packages/openapi-ts-tests/main/test/clients.test.ts -t '@hey-api/client-next'
• pnpm vitest run --project @test/openapi-ts packages/openapi-ts-tests/main/test/3.1.x.test.ts -t 'client with SSE (Next.js)'

[mrlubos]

@pullfrog review the latest version. Is this issue exclusive to the Next.js client?

[pullfrog]

Reviewed the latest version and submitted an approval. The bug is effectively exclusive to client-next due to its unique interceptor contract (interceptors mutate opts in place, unlike other clients which return a modified Request object).

Task list (4/4 completed)

• Checkout PR and read the diff
• Investigate whether the fix is exclusive to Next.js client
• Review code changes for correctness
• Submit review

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

[pullfrog]

The fix is correct and well-tested. To answer the question of whether this bug is exclusive to client-next — yes, effectively it is, because of an architectural difference in how interceptors work across clients.

In client-next, request interceptors receive the raw options object and mutate it in place (await fn(opts)). This means mutations to opts.baseUrl, opts.url, opts.path, or opts.query are the intended way to modify the request URL. The bug was that buildUrl was called before interceptors ran, so these mutations had no effect.

The other clients (client-fetch, client-ky, client-ofetch, client-angular) pass a Request object to interceptors (request = await fn(request, opts)). Users change the URL by returning a new Request with a different URL — they don't rely on buildUrl being re-invoked. So while buildUrl is also called before interceptors in those clients, it's not a bug because the interceptor contract is different (return a modified Request, not mutate opts).

client-axios delegates to Axios's own interceptor system (which operates on the config object including url), and client-nuxt uses ofetch's onRequest pattern. Neither suffers from the same issue.

One minor note on the SSE path: buildUrl(opts) is called before the SSE interceptors in onRequest, but the comment correctly explains that onRequest runs interceptors per-request and rebuilds via new Request(requestInit.url, requestInit). However, only direct requestInit.url mutations work there — baseUrl/path/query mutations on the cast requestInit object wouldn't trigger a URL rebuild. This is a pre-existing limitation (not introduced by this PR) and probably acceptable for the SSE use case.

Task list (4/4 completed)

• Checkout PR and read the diff
• Investigate whether the fix is exclusive to Next.js client
• Review code changes for correctness
• Submit review

  ^{｜ View workflow run ｜ 𝕏}