[native] possible #484 follow-up: "expected number" abort in large httpServe handler after await fetch (dune-server Hypery /oauth/token)

[spacedevin]

Summary

Production hit in dune-ide dune-server (native --feature http,http-hyper,…): after a successful browser Hypery PKCE login, the server aborted on the /oauth/token exchange path with:

thread 'main' panicked at src/main.rs:…:
expected number

This looks like the same f64 mis-promotion / from_value_expr(F64) class as #484 (non-number value live across await), but #484 is closed as fixed and a small standalone repro on current tip (v3.8.6 / 0.0.0-dev from main) does not panic.

Filing as a follow-up / incomplete-coverage report so the production shape is tracked.

Production shape (dune-server)

Handler sketch (pre-workaround) inside an httpServe / hyper callback — strings derived from the request body, used in an object after await fetch + await resp.text():

async fn handle(req) {
  let body = JSON.parse(typeof req.body === "string" ? req.body : "")
  let clientId = typeof body.clientId === "string" ? body.clientId.trim() : ""
  let web = typeof body.web === "string" ? body.web.trim() : "https://hypery.ai"
  while (web.length > 0 && web[web.length - 1] === "/") {
    web = web.slice(0, web.length - 1)
  }
  let form = "grant_type=authorization_code&client_id=" + encodeURIComponent(clientId) /* + … */
  let resp = await fetch(web + "/api/oauth/token", {
    method: "POST",
    headers: { "Content-Type": "application/x-www-form-urlencoded", "Accept": "application/json" },
    body: form
  })
  let text = await resp.text()
  let v = JSON.parse(text)
  // … validate access_token …
  return {
    ok: true,
    access_token: v.access_token,
    web_base: web,        // ← string local after await
    client_id: clientId   // ← string local after await
  }
}

In the large dune-server binary this aborted with expected number right as login completed (browser had already returned from Hypery authorize → /callback).

Workaround applied in dune-ide

Pin copies before the await and only use the pinned names after (same defensive pattern dune already uses around hypery_embed / tish#484 notes):

let webOut = "" + web
let clientIdOut = "" + clientId
let resp = await fetch(/* … */)
// …
return { web_base: webOut, client_id: clientIdOut, /* … */ }

What we tried on tip (does NOT panic)

On /Users/…/tish/target/release/tish (tish 0.0.0-dev, describes near v3.8.6):

1. Minimal [native] non-number param crossing an await in an async fn is mis-promoted to f64 → panic!("expected number") #484-style async fn f(s){ await …; return s } — not re-run here; assume still fixed per fix(native): cover S-0 object-field-value params in the numeric-arg whitelist (#484) #490.
2. Standalone await fetch + use web/clientId locals after await (same field extraction as above, invalid auth code so Hypery returns an error body) — completes, returns JSON error, no panic.
3. Classic webGet(apiUrl, apiKey, path) with apiKey used after await — OK on tip.

So this may only surface under whole-program inference of a large native binary (dune-server pulls in host-commands + serveWorkspace + agent pump), or via a slightly different value flow than the isolated case.

Ask

• Is there remaining risk for string locals / request-derived values that cross await inside large httpServe handlers under whole-program inference?
• Worth a regression test that embeds the exchange snippet in a non-trivial module graph (not a 30-line file)?
• If tip is considered fully fixed, a short note in the [native] non-number param crossing an await in an async fn is mis-promoted to f64 → panic!("expected number") #484 closing comment / landmines doc that call sites should still pin "" + x before await in large programs until confirmed would help consumers.

Refs

• Original: [native] non-number param crossing an await in an async fn is mis-promoted to f64 → panic!("expected number") #484 (fix fix(native): cover S-0 object-field-value params in the numeric-arg whitelist (#484) #490)
• Related class: Native serve() handler panics ('expected number') on ANY local let binding or capability-builtin call #477 / fix(native): don't native-promote params of value-escaping fns to f64 #479 / [native] sync 'return one of two params' fn mis-promotes a param to f64 -> panic!("expected number") (JS target OK) #485
• Consumer workaround landing in dune-ide serveWorkspace.tish /oauth/token and hypery_oauth_exchange

[spacedevin]

Root cause found (not the /oauth/token await-crossing theory)

The expected number abort at src/main.rs:17957 in the dune-server native build is buildConfigRequest's first parameter method being unboxed as f64:

let mut method = match &args.get(0).cloned().unwrap_or(Value::Null) {
  Value::Number(n) => *n,
  _ => panic!("expected number")
};

Callers pass string literals ("GET" / "PUT") via runConfig → buildConfigRequest(method, …). Whole-program inference in the large dune-server binary still mis-promotes that param.

That matches “crashes right after startup” when a browser tab hits hypery_config_list (config sync) immediately after listen — not necessarily OAuth.

Minimal shape:

export fn buildConfigRequest(method, suffix, body, apiUrl, token) {
  return { method: method, url: "…", headers: {}, body: body }
}
// linked into a large native binary; call with method = "GET"

Consumer workaround: let methodStr = "" + method at entry (landing in dune-ide).

This is closer to #485 / the numeric-arg whitelist gap than the async-crossing case in the original #484 writeup.

[spacedevin]

Confirmed: switching buildConfigRequest from positional (method, suffix, …) to a single object argument ({ method, suffix, body, apiUrl, token }) stops the native unbox. "" + method at the top of the old signature does not help — codegen still emits match args[0] { Value::Number(n) => *n, _ => panic!("expected number") } at param binding before any user statement runs.

Reproduced via POST /rpc { method: "hypery_config_list", … } against dune-server (browser config-sync on connect). After the object-arg change, the same RPC returns HTTP 200 and the process stays up.