Weird Server Actions bug when naming a path for a file

[GeorgeNabilPro]

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/nextjs-error-code-fccprj

To Reproduce

In my project, when some server action is called it calls the function saveFile, which looks like this:

async function saveFile(
  file: File,
  documentHash: string
) {
  const data = await file.arrayBuffer();
  await fs.appendFile(`./public/${documentHash}.pdf`, Buffer.from(data));
  return;
}

this goes well without any errors, however, when just changing the code to:

async function saveFile(
  file: File,
  documentHash: string
) {
  const data = await file.arrayBuffer();
  const path = `./public/assets/materials/${documentHash}.${file.name.split(".").pop()}`;
  await fs.appendFile(path, Buffer.from(data));
  return;
}

I tried many ways to add the file extension to the file path, but all of them caused the same error:

Error: Only plain objects, and a few built-ins, can be passed to Client Components from Server Components. Classes or null prototypes are not supported.
    at stringify (<anonymous>)

Current vs. Expected behavior

It is expected to have the file name with the proper extension, but this not happening

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
  Available memory (MB): 16126
  Available CPU cores: 20
Binaries:
  Node: 21.5.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.4 // Latest available version is detected (14.2.4).
  eslint-config-next: 14.2.4
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.2
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Runtime, Script (next/script)

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

No response

[GeorgeNabilPro]

Edit

I found that the problem is with the path being

./public/assets/materials/...

Because this directory did not exist on the system, when I tried to use a path like this:

./public/....

There were no errors. But still, I don't know what caused this weird behavior and why the error was not clear enough