The error leaks out from try/catch

[budarin]

Because canceling a request after a certain time is impossible (technically difficult to implement), so I'm trying to arrange a request race with a timer and if the timer is triggered earlier, we return undefined, otherwise the result of the request

const QUERY_TIMEOUT = 'query_timeout';

function sleep(ms) => new Promise((r) => setTimeout(() => r(QUERY_TIMEOUT), ms));

async function execQuery() {
  try {
    const query = sql`select * from func()`; // responds in 6 seconds SELECT pg_sleep(6);
    const response = await Promise.race([sleep(1000), query]);
    
    if (response === QUERY_TIMEOUT) {
      return;
    } else {
      return response
    }
  } catch(error) {
    console.log('PG error:', error);
  }
}

const data = await execQuery();

and in the database, a limit was set on the execution time of the statement

set statement_timeout = 5000

execute the code and get the error after getting the result from db:

{
  severity_local: 'NOTICE',
  severity: 'NOTICE',
  code: '00000',
  message: 'exception:\n' +
  '          \tmessage: query has no destination for result data\n' +
  '          \tstate  : 42601\n' +
  '          \tdetail : \n' +
  '          \thint   : If you want to discard the results of a SELECT, use PERFORM instead.\n' +
  '          \tcontext: \n' +
  '<NULL>',
  where: 'PL/pgSQL function func() line 5 at RAISE',
  file: 'pl_exec.c',
  line: '3893',
  routine: 'exec_stmt_raise'
}

Although it should not get errors at all because there has already been a return from this section of the code
In extreme cases, the code in the catch block should work and display an error in the log

PG error: query has no destination for result data

how is it defined in my code above

how to avoid the occurrence of an uncontrolled exception?

[spacepluk]

👋 you're missing an await in the query

I hope this helps other people hehe

[budarin]

await will wait for the request to be executed and will not proceed to the execution of the next line
Promise.race is just designed to wait for the execution of one of the promises in the array
await to break the intended logic

[e3dio]

Promise.race should have caught or handled error in this case, are you sure there was unhandledRejection or did error just get logged to console?

[budarin]

Promise.race, as expected, async/await is enclosed in a try/catch block to intercept errors

[e3dio]

Are you sure there was unhandledRejection or did error just get logged to console?

[budarin]

the application installs an unhandledRejection handler during initialization

[budarin]

at this point, the handler is a postmortem conclusion and not a solution to the issue of error interception in a specific place

[porsager]

@budarin I don't seem to be able to reproduce your issue, which I'm also a little unsure what it exactly is? Could you try to make a reproducible example showcasing what you get and what you expected?

[plopp]

Chiming in now that I stumbled upon this error too. I think this simple example reproduces the issue, at least on version 3.4.4.

Using:

• SvelteKit 2.0
• Svelte 4
• npm 10.2.4
• node 20.11.0

import postgres from "postgres";

const sql = postgres();

try {
  await sql.begin(async sql => {
    res_data = await sql`
        DO $$
        BEGIN
          RAISE NOTICE 'Example notice';
        END $$;`
  });
} catch (error) {
  console.error('Transaction error:', error);
} finally {
  await sql.end();
}

Expected result: The notice should get caught and the error string "Transaction error:" should be printed before the actual notice:

Transaction error: {
  severity_local: 'NOTICE',
  severity: 'NOTICE',
  code: '00000',
  message: 'Example notice',
  where: 'PL/pgSQL function inline_code_block line 4 at RAISE',
  file: 'pl_exec.c',
  line: '3923',
  routine: 'exec_stmt_raise'
}

Actual result:

{
  severity_local: 'NOTICE',
  severity: 'NOTICE',
  code: '00000',
  message: 'Example notice',
  where: 'PL/pgSQL function inline_code_block line 4 at RAISE',
  file: 'pl_exec.c',
  line: '3923',
  routine: 'exec_stmt_raise'
}

...assuming an emitted notice is actually an error.