You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
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
wws
Expected behavior
The workers returns the expected 200 response.
Additional context
Rust workers are working properly.
The text was updated successfully, but these errors were encountered: