Deno: lift "bad rid" panics in resources.rs into javascript exceptions (was: 'bad rid' panic when dialing localhost)

[MarkTiedemann]

// server.ts
import { serve } from "https://deno.land/std/http/server.ts";

async function main() {
  for await (let req of serve(":80")) {
    console.log(req.proto, req.method, req.url);
    req.respond({});
  }
}

main();

// test.ts
async function main() {
  let enc = new TextEncoder();
  let conn = await Deno.dial("tcp", ":80");
  conn.write(enc.encode("GET / HTTP/1.0\n"));
  conn.close();
}

main();

Ran server.ts, then ran test.ts in another window:

❯ deno run --allow-net test.ts
[1/1] Compiling file:///Users/marktiedemann/dev/deno_test/test.ts
thread '<unnamed>' panicked at 'bad rid', ../../cli/resources.rs:237:15
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
thread 'main' panicked at 'internal error: entered unreachable code', ../../third_party/rust_crates/registry/src/github.com-1ecc6299db9ec823/tokio-0.1.20/src/runtime/threadpool/mod.rs:296:26
thread 'main' panicked at 'unexpected state while aborting task: Complete', ../../third_party/rust_crates/registry/src/github.com-1ecc6299db9ec823/tokio-threadpool-0.1.14/src/task/mod.rs:216:21
stack backtrace:
   0:        0x10c034ab3 - <std::sys::unix::backtrace::tracing::imp::UnwindError as core::fmt::Display>::fmt::h91279d169ccb5b2c
   1:        0x10c02d6f2 - std::sys_common::alloc::realloc_fallback::h1ea3e7dd66f55875
   2:        0x10c031056 - std::panicking::take_hook::hf5878833b3146ef1
   3:        0x10c030d61 - std::panicking::take_hook::hf5878833b3146ef1
   4:        0x10c0317cf - std::panicking::rust_panic_with_hook::h547ea459e27be908
   5:        0x10c0312fc - std::panicking::begin_panic_fmt::hcacc0f82ca07e29f
   6:        0x10c031250 - std::panicking::begin_panic_fmt::hcacc0f82ca07e29f
   7:        0x10ce47c76 - <tokio_threadpool::task::Task::run::{{closure}}::Guard<'a> as core::ops::drop::Drop>::drop::h3e4ab556eba4c96c
   8:        0x10ce41e59 - tokio_threadpool::pool::state::<impl core::convert::From<tokio_threadpool::pool::state::Lifecycle> for usize>::from::h025a5dce3d6dcb6a
   9:        0x10ce499be - <tokio_threadpool::shutdown::ShutdownTrigger as core::ops::drop::Drop>::drop::hefa5d5ec07d4e8ed
  10:        0x10ce431db - <tokio_threadpool::worker::state::Lifecycle as core::fmt::Debug>::fmt::he88a1c5c815cc32d
  11:        0x10ce3d089 - tokio_threadpool::thread_pool::ThreadPool::shutdown_now::h6b270460ce9a5a1a
  12:        0x10ce1d8bc - tokio::runtime::current_thread::runtime::Runtime::run::hd4ea896f4ae076a4
  13:        0x10ce20160 - <tokio::runtime::threadpool::Runtime as core::ops::drop::Drop>::drop::h06f07afe0cfb18e8
  14:        0x10d0606fb - unicode_normalization::normalize::is_hangul_syllable::h3690a31bd91fba4a
  15:        0x10d135194 - unicode_normalization::normalize::is_hangul_syllable::h3690a31bd91fba4a
  16:        0x10d042b55 - unicode_normalization::normalize::is_hangul_syllable::h3690a31bd91fba4a
  17:        0x10c031167 - std::panicking::update_panic_count::hbf086650ecde3007
  18:        0x10c0414be - __rust_maybe_catch_panic
  19:        0x10c031c4d - std::rt::lang_start_internal::he82d111f45e8971a
  20:        0x10d1359f8 - main
thread panicked while panicking. aborting.
zsh: illegal hardware instruction  deno run --allow-net test.ts

When changing the addr to "localhost:80", the panic is gone and a proper error is printed instead:

Uncaught ConnectionRefused: Connection refused (os error 61)
    at DenoError (js/errors.ts:22:5)
    at maybeError (js/errors.ts:33:12)
    at handleAsyncMsgFromRust (js/dispatch.ts:41:17)
    at handleAsyncMsgFromRust (shared_queue.js:157:9)

[bartlomieju]

@MarkTiedemann I started digging into this issue; it turns out there's a mistake in the script - you're not awaiting conn.write and so connection is closed before write is started resulting in missing connection in resource table.

I wouldn't call it a bug, but error returned should be definitely more descriptive - it will be one of most common mistakes IMHO.

CC @ry

[ry]

@bartlomieju Good catch. I agree, failure is the expected behavior here.

That rust panic needs to be turned into a javascript panic. A JS stack trace would be more helpful.