@databases eats async stack traces

[petehunt]

Here's a repro. The line numbers still aren't right, but that's an issue with ts-node and my repro I think (it works in my main project). I think the issue is then-queue is not using native promises.

import connect, { sql } from "@databases/sqlite";

async function broken() {
  const db = await connect();
  await db.query(sql`this is an invalid sql statement`);
}

async function works() {
  const db = await connect();
  try {
    await db.query(sql`this is an invalid sql statement`);
  } catch (e) {
    throw new Error(e);
  }
}

async function main() {
  // if you uncomment broken(), the following is printed to stderr:
  // Error: SQLITE_ERROR: near "this": syntax error
  //await broken();

  // if you uncomment works(), the following is printed to stderr:
  await works();
  // Error: Error: SQLITE_ERROR: near "this": syntax error
  //   at /mnt/d/Repos/rowrm/src/repro.ts:13:11
  //   at step (/mnt/d/Repos/rowrm/src/repro.ts:37:23)
  //   at Object.throw (/mnt/d/Repos/rowrm/src/repro.ts:18:53)
  //   at rejected (/mnt/d/Repos/rowrm/src/repro.ts:10:65)
}

main().catch((e) => {
  console.error(e.stack);
  process.exit(1);
});

[ForbesLindesay]

then-queue is only used if you use queryStream so that isn't the culprit here. It could be caused by the fact that we're using babel to target node 12, so maybe something is lost at that point. It could also be because of the Mutex code, which is unfortunately necessary because SQLite does not support multiple concurrent transactions. We fake transaction support by taking an exclusive lock on the database for any transaction. The code for queueing that could mess with stack traces.

Having said all that, In your "works" example, I can't actually see the main function, so that doesn't have any async stack trace either, only the standard local stack trace, which happens to be more usable here because you threw the error in a function that provides some context to the error.