fix: use Response.redirect in redirectToPreviewURL

[angeloashmore]

Resolves:

Description

redirectToPreviewURL was using Next.js's redirect() from next/navigation, which throws internally to signal a redirect. This is incompatible with Route Handlers that need to return a Response. Switching to Response.redirect() makes the function return a proper response object and removes the dependency on Next.js internals.

Checklist

• A comprehensive Linear ticket, providing sufficient context and details to facilitate the review of the PR, is linked to the PR.
• If my changes require tests, I added them.
• If my changes affect backward compatibility, it has been discussed.
• If my changes require an update to the CONTRIBUTING.md guide, I updated it.

Preview

How to QA ¹

---

Note

Medium Risk
Changes the exported function’s return type and redirect mechanism, which may affect consumers relying on Next.js redirect() semantics or expecting a never-returning helper.

Overview
redirectToPreviewURL now returns a Response using Response.redirect(...) (307) rather than calling Next.js redirect() from next/navigation.

This updates the function signature from Promise<never> to Promise<Response> and constructs an absolute redirect target via new URL(previewURL, request.url) to be compatible with Route Handlers.

^{Written by Cursor Bugbot for commit 9441cc3. This will update automatically on new commits. Configure here.}

Footnotes

1. Please use these labels when submitting a review:
   ❓ #ask: Ask a question.
   💡 #idea: Suggest an idea.
   ⚠️ #issue: Strongly suggest a change.
   🎉 #nice: Share a compliment. ↩

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Base path redirect handling regressed

Medium Severity

Response.redirect(new URL(previewURL, request.url), 307) builds a raw URL and bypasses Next.js redirect normalization. When the app uses a basePath, redirects based on previewURL can resolve outside that prefix, sending users to the wrong path and causing preview routes to fail.

 

[angeloashmore]

This PR is no longer needed. The underlying fix was done in #133.