sst / sst

Build full-stack apps on your own infrastructure.
https://sst.dev
MIT License
22.01k stars 1.67k forks source link

[Bug] ".sst/artifacts/{PROJECT}/prerendered: copy_file_range: is a directory #3977

Open joanMelchor opened 1 month ago

joanMelchor commented 1 month ago

We are using sst in our project and after upgrading from version 3.1.78 our deployments started breaking. We haven't made any changes other than bumping the version, tried versions 3.2.0 to 3.2.6 but no luck, always the same error.

It's a sveltekit project. Full error:

Error: write /home/xxxx/xxxx/xxxx/.sst/artifacts/xxxx/prerendered: copy_file_range: is a directory
       at IncomingMessage.<anonymous> (file:///xxxx/xxxx/xxxx/xxx/.sst/platform/src/components/rpc/rpc.ts:42:22)
       at IncomingMessage.emit (node:events:529:35)
       at IncomingMessage.emit (node:domain:489:12)
       at endReadableNT (node:internal/streams/readable:1368:12)
       at processTicksAndRejections (node:internal/process/task_queues:82:21) {
     promise: Promise { <rejected> [Circular *1] }
   }

For now I'm fixing the version of the libray, again I haven't made any code changes other than updating the library version. Thanks for your help!

rayli09 commented 1 month ago

hitting same error cc @thdxr reproable on 3.2.11

I downgraded to 3.1.78 but I don't think it's fixing.


const migrator = new sst.aws.Function("SqliteMigrator", {
  handler: "./packages/core/src/migrator.handler",
  link: [...allSecrets],
  memory: "256 MB",
  copyFiles: [
    {
      from: "./packages/core/migrations",
      to: "./migrations",
    },
  ],
});
rracariu commented 1 month ago

Got similar error:

Failed    
Error: read /Users/foo/bar/.svelte-kit/svelte-kit-sst/prerendered: is a directory
at IncomingMessage.<anonymous> (file:///Users/foo/sst/.sst/platform/src/components/rpc/rpc.ts:42:22)
       at IncomingMessage.emit (node:events:531:35)
       at IncomingMessage.emit (node:domain:488:12)
       at endReadableNT (node:internal/streams/readable:1698:12)
       at processTicksAndRejections (node:internal/process/task_queues:90:21) {
     promise: Promise { <rejected> [Circular *1] }
   }
bigbyte-dom commented 1 month ago

Seeing the same issue on 3.2.12. Rolling back to 3.1.78 does the trick.

 Error: write /workspace/app/.sst/artifacts/XXXXXX-src/migrations: copy_file_range: is a directory
       at IncomingMessage.<anonymous> (file:///workspace/app/.sst/platform/src/components/rpc/rpc.ts:42:22)
       at IncomingMessage.emit (node:events:532:35)
       at IncomingMessage.emit (node:domain:488:12)
       at endReadableNT (node:internal/streams/readable:1696:12)
       at processTicksAndRejections (node:internal/process/task_queues:82:21) {
     promise: Promise { <rejected> [Circular *1] }
   }
rayli09 commented 1 month ago

Seeing the same issue on 3.2.12. Rolling back to 3.1.78 does the trick.

 Error: write /workspace/app/.sst/artifacts/XXXXXX-src/migrations: copy_file_range: is a directory
       at IncomingMessage.<anonymous> (file:///workspace/app/.sst/platform/src/components/rpc/rpc.ts:42:22)
       at IncomingMessage.emit (node:events:532:35)
       at IncomingMessage.emit (node:domain:488:12)
       at endReadableNT (node:internal/streams/readable:1696:12)
       at processTicksAndRejections (node:internal/process/task_queues:82:21) {
     promise: Promise { <rejected> [Circular *1] }
   }

dumb question: what steps did u follow to roll back?

for me i did

  1. change package.json and reinstall
  2. run sst install
  3. run sst deploy --stage but i'm still seeing a new err
    |  Error       
    |  Error: Could not resolve "unenv/runtime/node/fs/index" (originally "fs")
    |      at file:///Users/ruizeli/Documents/dev/offerplz/.sst/platform/src/components/cloudflare/worker.ts:396:17
    |      at processTicksAndRejections (node:internal/process/task_queues:95:5) {
    |    promise: Promise { <rejected> [Circular *1] }
    |  }

    which i'm very confused because this is new and I've not made any changes to cf provider

as a very temporary workaround, i just let chatgpt wrote this fn

import { allSecrets } from "./secret";
import * as fs from "fs";
import * as path from "path";

function getCopyFiles(
  sourceDir: string,
  targetDir: string,
): { from: string; to: string }[] {
  const results: { from: string; to: string }[] = [];

  function traverseDirectory(currentPath: string, targetPath: string) {
    const files = fs.readdirSync(currentPath);

    for (const file of files) {
      const fromPath = path.join(currentPath, file);
      const toPath = path.join(targetPath, file);
      const stat = fs.statSync(fromPath);

      if (stat.isDirectory()) {
        traverseDirectory(fromPath, toPath);
      } else {
        results.push({
          from: fromPath,
          to: toPath,
        });
      }
    }
  }

  traverseDirectory(sourceDir, targetDir);
  return results;
}

const migrator = new sst.aws.Function("SqliteMigrator", {
  handler: "./packages/core/src/migrator.handler",
  link: [...allSecrets],
  memory: "256 MB",
  copyFiles: getCopyFiles("./packages/core/migrations", "./migrations"),
  // FIXME: get back the the copy dir when https://github.com/sst/sst/issues/3977 is fixed
  // copyFiles: [
  //   {
  //     from: "./packages/core/migrations",
  //     to: "./migrations",
  //   },
  // ],
});

new aws.lambda.Invocation("SqliteMigratorInvocation", {
  functionName: migrator.name,
  input: JSON.stringify({
    now: new Date().toISOString(),
  }),
});
bigbyte-dom commented 1 month ago

confused because this is new and I've not made any changes to cf provider

as a very temporary workaround, i just let chatgpt wrote this fn

Yep, that's all I did:

change package.json 
    "sst": "3.1.78",

pnpm sst deploy --stage blah

The sst deploy triggered the dependency update for sst.

We use pnpm which is pretty good at picking up changes but npm has always been a bit pants. It might be worth checking whether you're using a global sst vs the package.json version? Or run npx npkill and blat your node modules and any lock files you have lying around and start fresh.

Our copyFiles has a trailing \, which I hope/assume isn't important but who knows! Will test without later.

E.g.

    copyFiles: [
      {
        from: `./migrations/`,
        to: './migrations/',
      },
Chung-Peter commented 4 weeks ago

I also ran into this issue and had to rollback to version 3.1.78 to get a successful deployment.