thread 'main' panicked at ext\websocket\lib.rs:723:29: called `Option::unwrap()` on a `None` value

[masx200]

Version: Deno 1.40.2

Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.

Platform: windows x86_64
Version: 1.40.2
Args: ["C:\\Users\\Administrator\\.deno\\bin\\deno.exe", "run", "--unstable", "-A", "./client.ts"]

thread 'main' panicked at ext\websocket\lib.rs:723:29:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[masx200]

https://github.com/masx200/websocket-proxy-deno-deploy/blob/5293345d125509bcbd5ee27528712d017769b14b/client.ts

[masx200]

error: Uncaught (in promise) TypeError: The stream controller cannot close or enqueue.
    at ReadableStreamDefaultController.enqueue (ext:deno_web/06_streams.js:6055:13)
    at pull (ext:deno_websocket/02_websocketstream.js:255:30)
    at eventLoopTick (ext:core/01_core.js:78:9)

[masx200]

I ran the socks server and websocket proxy server locally, then did a local speed test, and then the program crashed.

[y12studio]

I have a keen interest in this subject and intend to select option 4 to PR. Nonetheless, I am uncertain if this option is the best fit for this particular project. Since I lack comprehension of the project code, could someone kindly recommend an appropriate error term if I opt for option 4?

https://github.com/denoland/deno/blob/9a55a72cf195b2d5cee1e8598c7d28e4b1e8013a/ext/websocket/lib.rs#L723C2-L723C45

prompt: How to fix the Rust code throw error "called Option::unwrap() on a None value"

The error "called Option::unwrap() on a None value" indicates that you are attempting to unwrap an Option that contains None rather than Some(T). This results in a panic at runtime. In your scenario, .take() is returning None, leading to the error.

To fix this issue, you have several options depending on the intended behavior when resource.buffer is None. Here are some approaches:

1. Use match for Handling Both Cases

You can explicitly handle both Some(T) and None cases using match.

match resource.buffer.take() {
    Some(buffer) => Ok(buffer.into()),
    None => {
        // Handle the None case, e.g., by returning an error
        Err(/* your error here */)
    },
}

2. Use if let for Handling Only Some(T)

If you only care about the case where the buffer is present, you can use if let. However, you would still need to handle None in some way.

if let Some(buffer) = resource.buffer.take() {
    Ok(buffer.into())
} else {
    // Handle the None case
    Err(/* your error here */)
}

3. Use unwrap_or, unwrap_or_else, or unwrap_or_default for Default Handling

If there's a reasonable default value or a default action to take when None is encountered, you can use these methods.

// Using unwrap_or with a default value
Ok(resource.buffer.take().unwrap_or(default_value).into())

// Using unwrap_or_else with a closure to compute fallback
Ok(resource.buffer.take().unwrap_or_else(|| {
    // Compute default value
    default_value
}).into())

// Using unwrap_or_default, works if the inner type implements Default
Ok(resource.buffer.take().unwrap_or_default().into())

4. Propagate the Error

If it makes sense in your application, you can propagate an error if None is encountered using Option::ok_or or Option::ok_or_else.

Ok(resource.buffer.take().ok_or(/* your error here */)?.into())

Recommendation

It's generally best to avoid unwrapping unless you are certain the Option is Some(T). Handling None explicitly or using error propagation makes your code safer and more robust. Decide based on the context of your application which approach is most suitable.

[Bloodiko]

There needs to be a better Error message for content parsing.

Adding to this issue, i'm trying to run Deno (Fresh) in an air gapped env with an artifact storage in between, More or less similar behaviour than a proxy, but only kinda.

I mirrord deno.fresh and esm.sh and others into my local env, rewriting those to point to the "proxy" (which isnt a full proxy) which does work. The files are served as intended. Yet deno panicks, when something unexpected happens.

For example if I run deno cache https://deno.land/std@0.211.0/assert/assert_strict_equals.ts i get this error:

Download https://deno.land/std@0.211.0/assert/assert_strict_equals.ts
============================================================
Deno has panicked. This is a bug in Deno. [...]

Platform: linux x86_64
Version: 1.40.5
Args: ["deno", "cache", "https://deno.land/std@0.211.0/assert/assert_strict_equals.ts"]

thread 'main' panicked at cli/file_fetcher.rs:379:67:
called `Option::unwrap()` on a `None` value

But it does not elaborate on to why it was None and I dont know how to check. Curl does correctly retrieve the files contents.

This is not the only file. Sometimes it hangs at std/media_types/* or a similar file.

[lucacasonato]

This was fixed by https://github.com/denoland/deno/pull/21849