post-#609 regression: pool.query() returns an empty object — is undefined

[proggeramlug]

Summary

Following up on #609 (closed in v0.5.739): the native server now boots through migrations + the crypto KID step (the parameterized INSERT with a Buffer parameter no longer segfaults — thank you), but every subsequent read path fails because pool.query() returns an empty object instead of a { rows, rowCount, lastInsertId, ... } payload.

Concretely: Object.keys(await pool.query("SELECT 1")) is an empty array. JSON.stringify yields the empty string. .rows is undefined.

This was working in 0.5.706 (where I tested an earlier INSERT-then-SELECT repro for #609 and r.rows.length === 0 evaluated correctly).

Reproducer

import { Pool } from "@perryts/mysql";

async function main() {
  const pool = new Pool({ url: "mysql://root:@127.0.0.1:3306/test" });
  const r: unknown = await pool.query("SELECT 1 AS n");
  console.log("typeof r:", typeof r);
  console.log("JSON.stringify(r):", JSON.stringify(r));
  console.log("Object.keys(r):", Object.keys(r as object).join(","));
  await pool.end();
}
main().catch((e) => { console.error(e); process.exit(2); });

$ perry compile probe.ts -o probe && ./probe
typeof r: object
JSON.stringify(r): ""
Object.keys(r):

Same code under tsx probe.ts returns the expected shape.

A second repro showing the downstream impact:

const id = crypto.randomBytes(16);
await pool.query("CREATE TABLE probe (id BINARY(16) PRIMARY KEY, label VARCHAR(64))");
await pool.query("INSERT INTO probe (id, label) VALUES (?, ?)", [id, "hello"]);

const r1 = await pool.query("SELECT COUNT(*) AS n FROM probe");
console.log("count rows:", JSON.stringify(r1.rows));         // undefined

const r2 = await pool.query("SELECT label FROM probe WHERE id = ?", [id]);
console.log("by-id rows:", JSON.stringify(r2.rows));         // undefined

Both r1.rows and r2.rows are undefined. The INSERT appears to succeed (no error, no segfault) but I can't tell whether it actually persisted because the SELECT-back returns nothing recognizable.

Discovery context

The native server boots cleanly post-#609 fix:

[1/6] init MySQL pool
[2/6] run migrations
     applied: 0001_init.sql ... 0005_shop_timezone.sql
[3/6] ensure active crypto KID
[crypto] WARNING: Perry stdlib lacks AES; ...
     active kid: dek-moyi9zr3-055c8a4d        ← #609 fix worked
[4/7] start fastify
Server listening on http://0.0.0.0:18080

Then on the first POST /v1/auth/signup:

Error: createUser: row not found after insert

createUser is:

await exec("INSERT INTO users (id, email, passwordHash, ...) VALUES (?, ?, ?, ...)", [...]);
const row = await getUserById(id);
if (!row) throw new Error("createUser: row not found after insert");

getUserById calls queryOne which reads result.rows[0]. With the new return shape, result.rows is undefined → queryOne returns null → createUser throws. Same shape would break every other read path (signin's getUserByEmail, every cache lookup, every CRUD list endpoint).

Environment

• perry 0.5.739 (the version that closed post-#591 regression: exec(INSERT, [str, Buffer]) after SELECT segfaults the runtime #609)
• @perryts/mysql 0.1.3
• --target macos, arm64
• MySQL 9.6 (also reproduces against MySQL 8.0)

Why we filed

This is the only thing now blocking the native server binary. With #609's INSERT segfault fixed and this query-result regression resolved, we can flip our entire 24-suite e2e from tsx server/main.ts to ./build/server and ship a fully native production binary.

The fix likely needs to live alongside #609 — possibly the same NATIVE_MODULE_TABLE entry change that fixed the INSERT crash also altered how pool.query packages its return value to JS-land.

[proggeramlug]

The JSON.stringify(Buffer) crash is gone — thank you. But the original reported symptom of #639 is still present: pool.query("SELECT 1") returns an object whose own properties are empty, so .rows is undefined.

Re-tested the exact reproducer from the original filing on perry 0.5.765 (target/release rebuilt from 5746eac):

import { Pool } from "@perryts/mysql";
async function main() {
  const pool = new Pool({ url: "mysql://root:@127.0.0.1:3306/test" });
  const r: unknown = await pool.query("SELECT 1 AS n");
  console.log("typeof r:", typeof r);
  console.log("JSON.stringify(r):", JSON.stringify(r));
  console.log("Object.keys(r):", Object.keys(r as object).join(","));
  console.log("typeof r.rows:", typeof (r as { rows?: unknown[] }).rows);
  await pool.end();
}
main().catch((e) => { console.error("FATAL:", e); process.exit(2); });

$ perry compile probe.ts -o probe && ./probe
typeof r: object
JSON.stringify(r): ""
Object.keys(r): 
typeof r.rows: undefined

The new behavior: JSON.stringify no longer SIGSEGVs, but it returns "" (empty string) — the result object truly has no enumerable own properties. r.rows is genuinely undefined, not just unstringifiable.

Same pool.query under tsx returns { rows: [{ n: 1 }], rowCount: 1, ... } as expected.

Native server boot still passes through migrations + the crypto KID INSERT (✅ #609 fix), but on the first signup it dies in our dtRequiredToIso guard ("required datetime was null/zero") because getUserById's SELECT returns the r.rows undefined and queryOne falls back to null.

Suggested triage: the JSON.stringify(Buffer) fix in v0.5.761 may have been a symptom of this same bug (results couldn't be stringified because they had no enumerable props), but the root cause — that pool.query's return value isn't getting populated with the rows field on the perry-runtime side — looks separate. Possibly a JsValue::object() vs js_object_set_property ordering issue in the perry-stdlib mysql FFI binding.

Reopening attention here rather than filing a new issue since it's the same originally-reported symptom; happy to refile fresh if you'd prefer.