Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JavaScript workers are not properly working on Windows #135

Closed
Angelmmiguel opened this issue May 23, 2023 · 2 comments · Fixed by #136
Closed

JavaScript workers are not properly working on Windows #135

Angelmmiguel opened this issue May 23, 2023 · 2 comments · Fixed by #136
Assignees
Labels
🐛 bug Something isn't working
Milestone

Comments

@Angelmmiguel
Copy link
Contributor

Angelmmiguel commented May 23, 2023

Describe the bug

After adding a new end-to-end test suite on #134, the CI failed for JavaScript workers on Windows. I could reproduce the issue on a Windows machine and I'm researching the root cause now.

Reproduction steps

  1. Download the latest version of wws
  2. Download a basic JavaScript worker from the examples folder
  3. Run it
  4. Get a 503 error

Expected behavior

The workers returns the expected 200 response.

Additional context

Rust workers are working properly.

@Angelmmiguel Angelmmiguel added the 🐛 bug Something isn't working label May 23, 2023
@Angelmmiguel Angelmmiguel added this to the v1.1.2 milestone May 23, 2023
@Angelmmiguel Angelmmiguel self-assigned this May 23, 2023
@Angelmmiguel
Copy link
Contributor Author

Angelmmiguel commented May 23, 2023

After an initial research, I found a "5, Access Denied" error when trying to open the folder that includes the worker source code in Windows. Note that for interpreted language workers like JavaScript, wws relies on saving the source code into a temporary folder that will mount later.

In the case of JavaScript, this is the specific method that opens it:

fn prepare_wasi_ctx(&self, builder: WasiCtxBuilder) -> Result<WasiCtxBuilder> {
let source = fs::File::open(&self.store.folder)?;
Ok(builder.preopened_dir(Dir::from_std_file(source), "/src")?)
}

I need now to research why wws cannot open the folder that was created by the same process before.

@Angelmmiguel
Copy link
Contributor Author

Finally, the issue relied on the differences when opening a directory using fs::File. This is a valid operation in Unix, while failing with AccessDenied error in Windows. A lesson learned here is that we cannot rely on fs::File for working with directories.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant