Tokio panic when running lavarel locally

[linear]

I suspect this is a 'works on my machine' issue, but anyways.

Follow the steps:

• cd $(mktemp -d)
• composer create-project laravel/laravel wasmer-edge-laravel
• cd wasmer-edge-laravel
• copy toml from 'docs.wasmer.io/edge/guides/laravel#setup-a-wasmer-package'
• wasmer run .
• (in seprate terminal) curl localhost:8080

I get this:

Γ¥» wasmer run .
The current package is requesting networking access.
Run the package with `--net` flag to bypass the prompt.
? Would you like to allow networking for this package? [options: yes/no/always] (alwa
Γ£ö Would you like to allow networking for this package? [options: yes/no/always] ┬╖ always
[Tue Jan 14 04:46:47 2025] PHP 8.3.4 Development Server (http://localhost:8080) started
[Tue Jan 14 04:46:51 2025] 127.0.0.1:48856 Accepted
thread 'TokioTaskManager Thread Pool_thread_2' panicked at lib/virtual-fs/src/host_fs.rs:483:63:
called `Result::unwrap()` on an `Err` value: Os { code: 24, kind: Uncategorized, message: "Too many open files" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: Unable to wait for the process to exit
Γöé   1: RuntimeError: Thread manager disconnected
Γöé   2: RuntimeError: Thread manager disconnected
Γò░ΓöÇΓû╢ 3: Thread manager disconnected

Wasmer version 5.0.4

Running WSL2 ubuntu 22.04

[syrusakbary]

The "Too many open files" can be solved by doing ulimit -n 10240 or similar.

We'll need to refactor the WASIX FS to properly fix this issue I believe

[samuelmattjohnston]

We've migrated from wasmer to wasmtime due to this bug. The file descriptor ulimit increasing does not fix the issue when you're trying to reuse the created compiled wasms, only delays the inevitable file descriptor causing crash. We're trying to use wasms for processing ingress and egress of requests based on api permissions of the request, so we encounter this bug very quickly even when running a large ulimit.

manually calling tokio background cleanup for the wasmer runtime revealse a stacktrace crash we've been unable to root cause due to nesting of wasmer code, which might be related.