Getting "error: Read-only file system" for .graph cache file

[TooTallNate]

Starting with deno v1.0.3, a new .graph file seems to be output into the gen files in the deno cache alongside the other compiled files. For example:

 └── api
      ├── hello.ts.graph
      ├── hello.ts.js
      ├── hello.ts.js.map
      └── hello.ts.meta

I am deploying to a Lambda function which has a read-only filesystem where the deno cache resides (same setup as in #5688). For some reason, when executing deno run hello.ts from within the Lambda, deno decides to compile the hello.ts file again causing the command to fail:

Compile file:///var/task/hello.ts
error: Read-only file system (os error 30) (for '"/var/task/.deno/gen/file/var/task/hello.ts.graph"')

I'm not sure why this is happening (why deno considers that it needs to be compiled again), but it could be due to the fact that the .graph file contains absolute file paths, and the directory where the deno cache command is run is a different directory path than the where deno run command is run (the deno cache directory gets moved from a temp dir to /var/task in the runtime). So I'm thinking the (mismatching) absolute paths could be the culprit… Would re-writing those file paths to the correct destination directory prevent deno from trying to re-compile the TS file?

Or alternatively, is there a way to tell deno to never compile in the deno run command?

Also, out of curiosity, what is this new .graph file? I can't seem to find any mention of it in the release notes for v1.0.3.

[bartlomieju]

Thanks for the report @TooTallNate

I'm not sure why this is happening (why deno considers that it needs to be compiled again), but it could be due to the fact that the .graph file contains absolute file paths, and the directory where the deno cache command is run is a different directory path than the where deno run command is run (the deno cache directory gets moved from a temp dir to /var/task in the runtime). So I'm thinking the (mismatching) absolute paths could be the culprit… Would re-writing those file paths to the correct destination directory prevent deno from trying to re-compile the TS file?

This is most likely the cause, changing the paths should hot-fix this problem, but ultimately we need to fix it in Deno. I just realized that the same is valid for source map files.

Or alternatively, is there a way to tell deno to never compile in the deno run command?

Unfortunately not

Also, out of curiosity, what is this new .graph file? I can't seem to find any mention of it in the release notes for v1.0.3.

This file was introduced in #5029 to keep track of dependencies of compiled file - it's used to invalidate the cache if content of any of dependencies is changed. Unfortunately this made $DENO_DIR non-portable.

I'll look into this issue

[TooTallNate]

Thanks for the quick reply!

ultimately we need to fix it in Deno.

Great! Will this happen via relative file URIs (again, just curious)?

I just realized that the same is valid for source map files.

Also the .meta file! Though this isn't a problem for the read-only FS (as of v1.0.2 at least).

[TooTallNate]

Just wanted to chime in that the hot-fix of correcting the absolute file paths does indeed work. Here's a servereless function running Deno v1.0.5.

Still looking forward to the proper fix!

[TooTallNate]

I'm not sure if I should create a new issue, but basically the same problem is happening now with the .buildinfo files as of Deno v1.1.2 (if this should be a new issue then this one can probably be closed considering that .graph files are no longer a thing).

The same hot-patching method works for my purpose, though the patching buildinfo files is a bit more complicated now as the JSON structure is more complicated, but you can see what I did to make it working here: vercel-community/deno@0c38731

[bartlomieju]

@TooTallNate this issue is still on my radar - now that incremental compilation is working I'll see to make $DENO_DIR truly portable. I hope to get to it soon.

[bartlomieju]

@TooTallNate this issue should now be resolved - @kitsonk did massive refactors in the module grap infrastructure over the past year. I'm going to tentatively close this issue, please let me know if the problem persists.