Panic in Deno Flash server

[pschiffmann]

Deno Flash server crashes when it serves simple requests. Here is the full content of my src/main.ts file:

Deno.serve({
  handler(request) {
    console.log(request);
    return new Response("Hello world");
  },
  hostname: "0.0.0.0",
  port: 8889,
});

This is the request I send to my server from a browser:

fetch(new URL("/authenticate", serverUrl), {
      method: "POST",
      body: JSON.stringify({ accountName, password }),
      headers: { "content-type": "application/json" },
      mode: "no-cors",
    });

And this is the server console output. Interestingly, the browser receives the response before the server crashes.

~/projects/server % RUST_BACKTRACE=full deno task start
Warning deno task is unstable and may drastically change in the future
Task start deno run --unstable --allow-net=0.0.0.0:8889 src/main.ts
Listening on http://localhost:8889/
Request {
  bodyUsed: false,
  headers: Headers {
  accept: "*/*",
  "accept-encoding": "gzip, deflate, br",
  "accept-language": "de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7,fr;q=0.6",
  "cache-control": "no-cache",
  connection: "keep-alive",
  "content-length": "34",
  "content-type": "text/plain;charset=UTF-8",
  host: "localhost:8889",
  origin: "http://localhost:8888",
  pragma: "no-cache",
  referer: "http://localhost:8888/",
  "sec-ch-ua": '"Google Chrome";v="105", "Not)A;Brand";v="8", "Chromium";v="105"',
  "sec-ch-ua-mobile": "?0",
  "sec-ch-ua-platform": '"macOS"',
  "sec-fetch-dest": "empty",
  "sec-fetch-mode": "no-cors",
  "sec-fetch-site": "same-site",
  "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0...."
},
  method: "POST",
  redirect: "follow",
  url: "http://0.0.0.0:8889/authenticate"
}

============================================================
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: macos aarch64
Version: 1.25.1
Args: ["/opt/homebrew/bin/deno", "run", "--unstable", "--allow-net=0.0.0.0:8889", "src/main.ts"]

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', ext/flash/lib.rs:715:41
stack backtrace:
   0:        0x1032c5680 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9e1f971b6c458057
   1:        0x102af7da4 - core::fmt::write::hff50bf5ab34a8e88
   2:        0x1032ad300 - std::io::Write::write_fmt::h4b4cac536910ac0e
   3:        0x1032afb5c - std::panicking::default_hook::{{closure}}::h6afa39fd0b64edb8
   4:        0x1032af848 - std::panicking::default_hook::h0ab5dc1706bc4227
   5:        0x102aa8348 - deno::setup_panic_hook::{{closure}}::hef2108c53128687b
   6:        0x1032b046c - std::panicking::rust_panic_with_hook::h4f2beaf7e17e9f84
   7:        0x1032c59bc - std::panicking::begin_panic_handler::{{closure}}::h7bfd5963e591c8e8
   8:        0x1032c5954 - std::sys_common::backtrace::__rust_end_short_backtrace::ha8dd13728d5f8e85
   9:        0x1032affb0 - _rust_begin_unwind
  10:        0x102afa634 - core::panicking::panic_fmt::hd0caa445cceef50a
  11:        0x102afa724 - core::panicking::panic::had6482207444edec
  12:        0x102cab8c8 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h34fffaa9562104af
  13:        0x102cab158 - <extern "C" fn(A0) .> R as v8::support::CFnFrom<F>>::mapping::c_fn::h97220c381c8504c5

[pschiffmann]

I think this error happens when I don't await the request body in the handler.

// panic
handler(request) {
  request.text();
  return new Response("Hello world");
}

// no panic
async handler(request) {
  await request.text();
  return new Response("Hello world");
}

[sant123]

Same happens with http/std. It seems we need to use await in both case:

[sagea]

I am working on this. I will put up a pr shortly.

[sagea]

This bug also surfaces when attempting to read the request headers.

[sant123]

Same happens with http/std. It seems we need to use await in both case:

This no longer happens in Deno v1.29.1

[bartlomieju]

Thanks for checking @sant123, I'm gonna close this issue for now.