`useQuery` swallows underlying Kysely errors

[KazimirPodolski]

Using Kysely adapter, this properly throws an error:

computedAsync(async () => await db.selectFrom('ololo').selectAll().execute());

kysely:error: Error: no such table: ololo
    at check (sqlite-api.js:889:11)
    at sqlite-api.js:738:13
    at async WorkerWASQLiteConnection._execute (WASQLiteConnection.js:361:26)
    at async WorkerWASQLiteConnection.executeSingleStatement (WASQLiteConnection.js:331:25

while this doesn't:

useQuery(db.selectFrom('ololo').selectAll());

It just silently doesn't work, the console is empty.

[KazimirPodolski]

I just realized that the error will be in the useQuery's return object... should there be an option to throw automatically instead? I'm pretty sure query error is normally a programming error, not userspace error.

[stevensJourney]

For the non-suspending useQuery, I don't think throwing is the right default.
The query runs asynchronously after render, so throwing from that async path would most likely result in an uncaught exception rather than something React can handle through an ErrorBoundary.

I suspect most of these errors in practice will be development-time issues: invalid SQL, missing tables or columns, bad Kysely-generated queries, or schema/query mismatches. For those cases, a loud development signal is useful.

But there are also less common runtime failures that we shouldn't ignore, such as SQLite disk I/O errors, VFS/filesystem errors. Those can happen in production, and in that case exposing the error without throwing is still valuable.

Some ideas we could consider:

In development mode, throwing an uncaught exception might be a nice indicator. It looks like we don't log these errors. We could expose this a bit better by logging these errors using the PowerSyncDatabase's logger - I think this would help a lot with discovery.