Invalid file path on startup for relative imported modules / files

[devidevio]

Bug report

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

Describe the bug

I'm running the supabase edge-runtime in a self hosted environment. Since the upgrade from supabase/edge-runtime:v1.5.2 to the latest available version supabase/edge-runtime:v1.7.2 I'm getting the following error on the container startup:

Failed to load module: "file:///home/deno/functions/_shared/headers.ts" - Invalid file path.
  Specifier: file:///home/deno/functions/_shared/headers.ts
CPU time used: 13ms
Error: worker boot error

The setup is exactly the same as described in the example here.

It works as expected on supabase/edge-runtime:v1.6.0.

I'm mounting the functions directory as described in the docker example file here.

volumes:
      - ./volumes/functions:/home/deno/functions:Z

It seems like there is a / (slash) to much (3 instead of 2) in the file path where it tries to load the file.

Expected behavior

The local file / module import works as expected.

Currently:
file:///home/deno/functions/_shared/headers.ts

Should be / correct:
file://home/deno/functions/_shared/headers.ts

[laktek]

Can you upgrade to edge-runtime 1.8.2 and see if it fixes the issue?

[devidevio]

Checked on version 1.8.2 and 1.9.0 (latest available for now) and still the same error on container startup:

Failed to load module: "file:///home/deno/functions/_shared/headers.ts" - Invalid file path.
  Specifier: file:///home/deno/functions/_shared/headers.ts

Tried to import the headers.ts with and without the extension (.ts).

The latest stable and for me working version is 1.6.0.

[sandeepuno]

its working for us @1.9.0. Please update the main.ts
3288f8b#diff-e0cd37e1a18fe936ed378c94a5b2ceda7cd50465278766753934c8554b05a120L58

[devidevio]

Thanks for your response, still getting the same error @1.9.0.

I digged a little bit through the latest commits and versions and noticed that everything works fine until @1.6.2 and breaks at @1.6.3.

There I found this commit / change which is related to @1.6.3:

• a03877b

Seems related to this commit, can you have a look at it?

Regardless if I keep the customModuleRoot set to '', null or without the setting at all.

[laktek]

Can you share your main/index.ts? If you remove customModuleRoot from createWorker options, you shouldn't get this error.

[devidevio]

The part for the workers is exactly the same as described in the example:

• https://github.com/supabase/edge-runtime/blob/main/examples/main/index.ts

--- EDIT ---

I'm pretty sure to know where's the error. As already mentioned, it stopped to work for me with v1.6.3, here are the changes:

• a03877b

If digged a little bit more into the changes and found especially this change, which also gives me the exact error on container startup:

• a03877b#diff-35a2ebf14ef1b4ca6dc53093ca65de4a4152d61b1690e1cba876e6aaa6f8a371L15

This check I'm referring to:

• https://github.com/supabase/edge-runtime/blob/main/crates/module_fetcher/src/permissions.rs#L20-L33

As far as I understand (I'm not familiar with Rust) the functions checks, if a locally imported file / file path does not start with &self.root_path (should be the current directory) it throws the error I'm getting.

Now I don't know what the values for file_path and &self.root_path are. I assume, that the file_path is holding the value file:///home/deno/functions/_shared/headers.ts. Could it be by any chance, that the &self.root_path does not start with file:// and the check breaks? For example:

• file_path= file:///home/deno/functions/_shared/headers.ts
• &self.root_path = /home/deno/functions/

As far as I understand, the file:// prefix should be removed from the file_path before checking against the value of &self.root_path?

Thanks so far.

[devidevio]

Are there any updates on this topic?

Thanks in advance.

[tvogel]

I was hunting down the customModuleRoot option only to find out now that it has been removed meanwhile, at least it is ineffective since: 9f24d74