Error: `Cannot redefine property: $$id` in `action-proxy.ts`

[shunkakinoki]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.16.1
      npm: 9.8.0
      Yarn: 1.22.19
      pnpm: 8.6.10
    Relevant Packages:
      next: 13.4.19
      eslint-config-next: 13.4.19
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.2.2
    Next.js Config:
      output: N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

App Router

Link to the code that reproduces this issue or a replay of the bug

WIP

To Reproduce

WIp

Describe the Bug

Cannot build the action w/ the server proxy

Expected Behavior

Builds without bug

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

[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 for App Router, template for Pages Router), but you can also use these templates: CodeSandbox: App Router or CodeSandbox: Pages Router.

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. Ensure your reproduction does not depend on secrets, 3rd party registries, private dependencies, or any other data that cannot be made public. Avoid a reproduction including a whole monorepo (unless relevant to the issue). The easier it is to reproduce the issue, the quicker we can help.

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

If you cannot create a clean reproduction, another way you can help the maintainers' job is to pinpoint the canary version of next that introduced the issue. Check out our releases, and try to find the first canary release that introduced the issue. This will help us narrow down the scope of the issue, and possibly point to the PR/code change that introduced it. You can install a specific version of next by running npm install next@<version>.

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 reproduction 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

[kristinlindquist]

In case anything short of a minimal repo helps: I also see this on 13.4.19 but not on 13.4.18. While it seems unlikely to be the cause, I am on MacOS like the OP. I'm using app router.

[shanehoban]

Also seeing this on 13.4.19 - working on 13.4.18. On Ubuntu via WSL.

[matbeedotcom]

Seeing it on 13.5

[rawi96]

I don't know if it helps but:

I had the same error because i was exporting the server action wrong.
It worked on 13.4.18 but not on 13.4.19 and higher.

/src/app/page.tsx

"use client";

import { myServerAction } from "./my-server-action";

export default function ClientComponent() {
  const handleClick = () => {
    console.log("console log from client");
    myServerAction();
  };

  return <button onClick={handleClick}>execute server action</button>;
}

/src/app/my-server-action.ts

"use server";

export const myServerAction = () => {
  console.log("console log from server");
};

export default myServerAction;

Then I realized that I was exporting the server action twice. 1x where I define the function and 1x below as default.

As soon as I only do 1 of the two and adjust the import in the tsx page accordingly, it also works on next 13.5.4

[JoshuaHull]

I was putting together a reproduction and eventually reached the same realisation as rawi96 - if you have a file with the "use server" directive which is exporting a component/action once named and again as a default, you will hit this issue.

I've removed all instances of double exporting and am happily building on 13.5.

"use server";

export const ProblematicComponent = () => {
  return <div>I am breaking the build on 13.5+ as I am exported twice</div>;
}

export default ProblematicComponent;
^^^^^^^ remove me

Reproduction is here:
https://github.com/JoshuaHull/nextjs-54655-repro

[lisboaa]

@JoshuaHull Nice, this really was a problem, I made the modification and it worked.

[collinversluis]

I was putting together a reproduction and eventually reached the same realisation as rawi96 - if you have a file with the "use server" directive which is exporting a component/action once named and again as a default, you will hit this issue.

I've removed all instances of double exporting and am happily building on 13.5.

"use server";

export const ProblematicComponent = () => {
  return <div>I am breaking the build on 13.5+ as I am exported twice</div>;
}

export default ProblematicComponent;
^^^^^^^ remove me

Reproduction is here: https://github.com/JoshuaHull/nextjs-54655-repro

Nice! This solves it for me. Odd but working. Thanks!

[samislam]

I am using the latest version of nextjs with the ap14p router.
Version 14.0.3 as of the time of writing the comment.

The problem in my case was a file in my source code which had the "use server" declarative, which was exporting a named export and a default export of the same variable.

"use server"
export const SelectCompany = ()=> <div></div>
export default SelectCompany

The solution was to either use export default or export const.
I removed the named export export const. And failed back to the default export, and the error message went away.

Anyway, it's a bug. But that's one work-around which may help someone to survive during development.

[chriscarrollsmith]

I don't know if it helps but:

I had the same error because i was exporting the server action wrong. It worked on 13.4.18 but not on 13.4.19 and higher.

/src/app/page.tsx

"use client";

import { myServerAction } from "./my-server-action";

export default function ClientComponent() {
  const handleClick = () => {
    console.log("console log from client");
    myServerAction();
  };

  return <button onClick={handleClick}>execute server action</button>;
}

/src/app/my-server-action.ts

"use server";

export const myServerAction = () => {
  console.log("console log from server");
};

export default myServerAction;

Then I realized that I was exporting the server action twice. 1x where I define the function and 1x below as default.

As soon as I only do 1 of the two and adjust the import in the tsx page accordingly, it also works on next 13.5.4

D'oh! Thanks for this. Turns out I had two export statements; one in the function declaration, and one at the end of the file. So, in effect, the server action was being redundantly initialized.