I confirmed this revert makes the following test execution non-flaky in deno_std:

$HOME/denoland/deno/target/debug/deno task node:test -- test-http-url

(also confirmed main is flaky with the above command)

I reduced the example of segfault to the below (no std involved):

const ctl = new AbortController();
Deno.serve(() =>
  new Promise((resolve) => {
    resolve(new Response(new TextEncoder().encode("ok")));
    ctl.abort();
  }), {
  signal: ctl.signal,
  onListen() {
    fetch("http://localhost:9000", { method: "POST" });
  },
});

Note:

• The response body needs to be Uint8Array. If string is given, the segfault doesn't happen.
• The request method needs to be "POST". If it's "GET", the segfault doesn't happen.
• segfault happens like 90% of the case, not always.

(I'll add this as a test case).

If I removed the line of ctl.abort() from the above, it panics with the error thread 'main' panicked at 'called "Option::unwrap()" on a "None" value', ext/flash/lib.rs:747:41

I found that your snippet seems to be panicking for Deno v1.27.2 too. The difference is that on v1.27.2 it never segfaults (i.e. it always panics here, which is the same line as the panic log you pasted) regardless of the presence of ctl.abort(), whereas on the latest main it behaves like you described.

Ah, sorry. The above seems panicking on a different problem 😓

Please use the below instead:

const ctl = new AbortController();
Deno.serve(() =>
  new Promise((resolve) => {
    resolve(new Response(new TextEncoder().encode("ok")));
    ctl.abort();
  }), {
  signal: ctl.signal,
  async onListen({ port }) {
    const a = await fetch(`http://localhost:${port}`, { method: "POST", body: "" });
    await a.text();
  },
});

(body is added in fetch option)

This finishes with 0 with v1.27.2 and segfaults with canary/main.

I suppose the cause is that now (after #16383) close operation is synchronous, causing the resources related to flash to be cleaned up immediately - in fact, if we update op_flash_close_server to the following, the issue seems to be resolved.

#[op]
async fn op_flash_close_server(state: Rc<RefCell<OpState>>, server_id: u32) {
  let ctx = {
    let op_state = &mut state.borrow_mut();
    let flash_ctx = op_state.borrow_mut::<FlashContext>();
    flash_ctx.servers.remove(&server_id).unwrap()
  };

  // Key: yield to the event loop once
  deno_core::futures::pending!();

  let _ = ctx.waker.wake();
}

But I feel we could improve the code above further. I'll try to come up with that.

@magurotuna Nice! But I'm landing this for now to unblock the std's CI.

Yeah I agree with that. I'll continue working on another PR.