Skip to content

Change Postgres query error logging from error to warn #118

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
owens1127 merged 1 commit into from
Feb 22, 2026
Merged

Change Postgres query error logging from error to warn #118

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/integrations/postgres/shared.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@
} catch (error) {
const executeTime = Date.now() - startTime
const err = error instanceof Error ? error : new Error(String(error))
logger.error("QUERY_ERROR", err, {
logger.warn("QUERY_ERROR", err, {

Copilot AI Feb 22, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing all query errors from error to warn level is too broad and will hide genuine database errors that should be sent to Sentry. This blanket change means that connection failures, permission issues, constraint violations, and other critical database errors will no longer be tracked in Sentry.

The PR description mentions that "Admin query failures, though gracefully handled by API, are prematurely sent to Sentry". Looking at the admin query route (src/routes/admin/query.ts), it catches DatabaseError specifically and handles syntax errors gracefully. However, this is a specific use case where query errors are expected and handled.

A better solution would be to:

  1. Keep logger.error for genuine unexpected errors
  2. For the admin query endpoint specifically, either catch and handle the error before it reaches executeQuery, or add a parameter to executeQuery to control logging level based on whether errors are expected
  3. Alternatively, add context to distinguish between expected errors (like admin query syntax errors) and unexpected errors (connection failures, permission issues, etc.)

This change affects all database operations across the entire application, not just admin queries.

Copilot uses AI. Check for mistakes.
duration: `${executeTime}ms`,
operation,
sql: sql.substring(0, 200)
Expand Down Expand Up @@ -97,18 +97,18 @@
)
}, 5000)

pool.on("error", err => {

Check warning on line 100 in src/integrations/postgres/shared.ts

View workflow job for this annotation

GitHub Actions / test 

100 line is not covered with tests
logger.error("POOL_ERROR", err, { pool: config.name })
})

process.on("beforeExit", () => {
clearInterval(metricsInterval)
pool.end().catch(err => {
logger.error(
"POOL_CLEANUP_ERROR",
err instanceof Error ? err : new Error(String(err)),
{}
)

Check warning on line 111 in src/integrations/postgres/shared.ts

View workflow job for this annotation

GitHub Actions / test 

104-111 lines are not covered with tests
})
})

Expand Down