hono: app.get("/users/:id") + app.notFound() handlers produce no output on perry-compiled binary

[proggeramlug]

Summary

A hono fixture exercising a static route, a :id-param route, and a notFound handler prints only the first response under perry; the second and third app.fetch() calls produce no stdout. Node prints all six expected lines.

Reproducer

tests/release/packages/hono-basic/ fixture (added to the release-sweep harness this cycle):

// entry.ts
import { Hono } from "hono";

const app = new Hono();
app.get("/", (c) => c.json({ hello: "world" }));
app.get("/users/:id", (c) => c.json({ id: c.req.param("id"), name: `User ${c.req.param("id")}` }));
app.notFound((c) => c.text("not found", 404));

async function main() {
    const r1 = await app.fetch(new Request("http://x/"));
    console.log(`r1.status=${r1.status}`);
    console.log(`r1.body=${await r1.text()}`);
    const r2 = await app.fetch(new Request("http://x/users/42"));
    console.log(`r2.status=${r2.status}`);
    console.log(`r2.body=${await r2.text()}`);
    const r3 = await app.fetch(new Request("http://x/missing"));
    console.log(`r3.status=${r3.status}`);
    console.log(`r3.body=${await r3.text()}`);
}
main();

{
  "dependencies": { "hono": "^4.6.0" },
  "perry": { "compilePackages": ["hono"] }
}

Expected (from Node)

r1.status=200
r1.body={"hello":"world"}
r2.status=200
r2.body={"id":"42","name":"User 42"}
r3.status=404
r3.body=not found

Actual (from perry-compiled binary)

r1.status=200
r1.body={"hello":"world"}

— first call passes byte-for-byte; the second and third silently produce nothing. The process exits 0, so the second/third app.fetch() returns something; whatever it returns has empty .text() AND no .status.

Why this matters

#421 (single-route hello world) closed in v0.5.613. Followups for routes-with-params and JSON responses were noted as out-of-scope under #486 / #487. This is the smallest possible regression-catcher fixture for that gap; it now lives in-tree so a future fix can flip it from FAIL to PASS as an acceptance signal.

Likely overlaps with hono's RegExpRouter / TrieRouter codegen path (param extraction). Could also be the c.req.param() accessor — would help to bisect by replacing the param route with a non-param fallback that still uses c.json({...}) but no c.req.param(...).

Environment

• Perry 0.5.699
• hono ^4.6.0
• macOS 26.4 / arm64
• Discovered via scripts/release_sweep.sh --tier=3 (tests/release/packages/hono-basic/)

Refs #421, #486, #487.

[proggeramlug]

Bisected. The fixture's silent failure after the first call is the surface of three stacked bugs:

• async-step driver: sync throw from iter.next() bypasses user catch and resolves to undefined #619 — async-step driver swallows sync throws from iter.next() as Promise.reject instead of routing through iter.throw to the user's catch. Plus the throw closure swallows errors when there's no user catch (should rethrow).
• class instance property reassignment ignored: this.method = X dispatched to prototype, not own property #620 — this.method = X in a class method body is ignored: Perry's class-method dispatch always hits the prototype/vtable, not the own-property override. Hono's SmartRouter.match rebinds itself on the first call (this.match = router.match.bind(router)) for fast-path dispatch; on the second call Perry hits the original method, which throws Error("Fatal error") because this.#routes was set to undefined on the first call.
• generator transform: throw closure terminates with done=true after catch instead of continuing past try/catch #621 — even with async-step driver: sync throw from iter.next() bypasses user catch and resolves to undefined #619 fixed, statements after a try/catch in an async function never run on the catch path: the throw closure ends with __gen_done = true; return { done: true } instead of transitioning to a post-catch state.

#620 is the proximate cause of "every call after the first throws" in the hono path. #619 and #621 are why the throw is invisible (silent exit / swallowed) rather than surfacing as an error.

Closing this fixture's parity gap end-to-end likely needs all three fixed (or hono's SmartRouter pattern worked-around a different way). Repros + fix sketches in each linked issue.

[proggeramlug]

v0.5.715 lands fixes for the three bisected blockers (#619, #620, #621). Each has an isolated regression test (test-files/test_issue_619.ts / test_issue_620.ts / test_issue_621.ts) passing byte-for-byte vs Node.

The hono-basic fixture still doesn't pass end-to-end — bisected to one more upstream bug filed as #628: invoking a class-method bound closure stored as a local variable (const m = router.match; m(...)) returns undefined. Hono's SmartRouter this.match = router.match.bind(router); this.match(...) chains through this dispatch on the second call.

Once #628 lands, the hono-basic fixture should flip from FAIL to PASS without further changes here.

[proggeramlug]

v0.5.721 (#628) closed the third bisected blocker. v0.5.722 added a parallel #620 fix for the dynamic-dispatch path so type-erased receivers (hono's this.router typed as Router interface) also honor own-property overrides — test_628_dyn and the SmartRouter mocks all match Node.

Hono fixture status: dispatch chain now flows all three calls (no more silent exit on r2). But routes return 404 instead of 200/200/404, with new js_box_get: invalid box pointer 0x0 warnings — filed as #632 to track.

Once #632 lands, this fixture should pass.

[proggeramlug]

v0.5.726 fixes #632 (hono r1 = 200/{"hello":"world"} matches expected). r3 (/missing) also correct (404/"not found"). r2 (param route /users/:id) still returns 404 — filed as #633.