npm package broken by >v1.60.1

[johnstonmatt]

Bug report

If I deploy the following function it works on v1.60.1 but crashes on all later versions:

import { say } from "npm:cowsay";

Deno.serve((req) => {
  const { pathname } = new URL(req.url);
  if (pathname !== "/cowsay") {
    return new Response("Not Found", {
      status: 404,
    });
  }
  const query = new URL(req.url).searchParams;
  const text = query.get("message");

  if (!text || typeof text !== "string" || text.length === 0) {
    return new Response("Please provide a message", {
      status: 400,
    });
  } else {
    return new Response(say({ text }), {
      headers: {
        "Content-Type": "text/plain",
      },
    });
  }
});

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

[nyannyacha]

Hello @johnstonmatt

My guess is that the crash you're talking about is the following error message.

PermissionDenied: Deno.readFileSync is blocklisted
    at Object.readFileSync (ext:sb_core_main_js/js/bootstrap.js:403:9)
    at Object.readFileSync (ext:deno_node/_fs/_fs_readFile.ts:52:21)
    at exports.get (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/cowsay/1.6.0/lib/cows.js:25:13)
    at doIt (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/cowsay/1.6.0/index.js:144:17)
    at exports.say (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/cowsay/1.6.0/index.js:57:9)
    at Object.handler (file:///workspaces/edge-runtime-shadow/examples/serve/index.ts:16:25)
    at respond (ext:sb_core_main_js/js/http.js:197:38)
    at handleHttp (ext:sb_core_main_js/js/http.js:131:5)
    at eventLoopTick (ext:core/01_core.js:168:7) {
  name: "PermissionDenied"
}

Yeah, this error was introduced after 1.60.1 and is reproducible.
However, there is background to this.

We run worker units sequentially on the tokio async worker thread to allocate CPU resources to workers that are executing the user's function.

The problem here is that if we are allowing an API such as readFileSync inside the worker, which can make the tokio thread a blocking status, means that the next worker cannot be run until it returns a value, which causes delays for all workers that are running.

To prevent such issues, I have been considering improving the scheduling, but due to the structural problems of our upstream Deno, there are limitations to improving this immediately.

We currently block the call to readFileSync unconditionally, but we may allow the call to this API if the payload to be loaded is small enough (However, I believe that this will require sufficient consultation with other maintainers.)

So, I have no choice but to say that such crashes were intentional.

I am sorry that we cannot provide a solution at this time. However, I think we will be able to improve this in the future.

[johnstonmatt]

You're right about the error message.

Thanks for the heads-up! I'll not avoid upgrading to prevent the issue as I'd initially planned.