Components do not receive SSR/SSG props on loopback redirects with hash

[anders-nom]

What version of Next.js are you using?

11.1.2

What version of Node.js are you using?

16.8.0

What browser are you using?

Chrome

What operating system are you using?

Windows 10/Alpine Linux

How are you deploying your application?

next start

Describe the Bug

This bug has been observed when redirecting via a SSR or SSG dynamic route under these conditions:

• The client-side source and redirect destination paths are the same
• The path which triggers the redirect is handled by same route as the source/destination path
• The source and/or destination URL contains a hash (including an empty hash)

If all these conditions are true, the component exported from the route does not receive the props returned from the getServerSideProps/getStaticProps function. Instead, an internal next.js redirect object is received, i.e. { __N_REDIRECT: "/myPage", __N_REDIRECT_STATUS: 307 }

Example: the user is currently viewing /myPage#myHash, and clicks a link which redirects to /myPage (with or without a hash). If this redirect happens within the same dynamic route that handles /myPage, the component exported from this route will receive incorrect props as described above. However, if the redirect is handled in a separate route, no problem seems to occur and the correct props are received.

Our current workaround for the issue is to check for the __N_REDIRECT value in the props of the exported component, and run router.reload() when it is present.

Expected Behavior

Components exported from an SSR/SSG route should always receive the props returned from getServerSideProps/getStaticProps.

To Reproduce

• Clone https://github.com/anders-nom/nextjs-hash-redirect-bug
• npm run build
• npm run start
• Go to http://localhost:3000
• Click the link which leads to /myPage#myHash
• Observe the aforementioned behaviour when clicking the second link on this page, which triggers a redirect through the same catch-all route that handles /myPage. The first link will however work as expected, as the redirect happens in a separate route.

[github-actions]

We cannot recreate the issue with the provided information. Please add a reproduction in order for us to be able to investigate.

Why was this issue marked with the please add a complete reproduction label?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository (template), but you can also use a tool like CodeSandbox or StackBlitz.

To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue.

Please test your reproduction against the latest version of Next.js (next@canary) to make sure your issue has not already been fixed.

I added a link, why was it still marked?

Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.

What happens if I don't provide a sufficient minimal reproduction?

Issues with the please add a complete reproduction label that receives no meaningful activity (e.g. new comments with a reproduction link) are automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue with the required reproduction.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without repro steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[balazsorban44]

This issue has been automatically closed because it wasn't verified against next@canary. If you think it was closed by accident, please leave a comment. If you are running into a similar issue, please open a new issue with a reproduction. Thank you.

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.