postgres
postgres copied to clipboard
The error leaks out from try/catch
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?
👋 you're missing an await in the query
I hope this helps other people hehe
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
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?
Promise.race, as expected, async/await is enclosed in a try/catch block to intercept errors
Are you sure there was unhandledRejection or did error just get logged to console?
the application installs an unhandledRejection handler during initialization
at this point, the handler is a postmortem conclusion and not a solution to the issue of error interception in a specific place
@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?