This repository has been archived by the owner on Aug 3, 2023. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Temporary workaround to avoid dropping a tokio::runtime while another…
… is running This fixes the following error from `wrangler tail`: ``` $ wrangler tail 🦚 Setting up log streaming from Worker script "test-project". Using ports 8080 and 8081. This may take a few seconds... Oops! wrangler encountered an error... please help Cloudflare debug this issue by submitting an error report (/home/jnelson/.wrangler/errors/1625847335787.log) To submit this error report to Cloudflare, run: $ wrangler report Closing tail session... Error: panic ``` The panic in that file is "Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context." The larger issue is that there are many different runtimes in Wrangler: - A runtime created by `wrangler tail` to watch for changes - A runtime created by `reqwest::blocking` to fetch the account ID from Cloudflare's API - A runtime in `commands::dev::gcs` - not sure what this does, something to do with a persistent server? - A runtime in `commands::dev::edge` - ditto Having more than one runtime going at once is not great; the three in Wrangler seem to be disjoint, but the one in cloudflare_rs absolutely overlaps with some of the ones from wrangler. This is a temporary workaround to avoid panics in `wrangler tail`, but I'm working on a larger fix to cloudflare_rs to see if it can avoid spawning a new runtime for each request.
- Loading branch information