Change Postgres query error logging from error to warn

[seer-by-sentry]

Fixes API-12. The issue was that: Admin query failures, though gracefully handled by API, are prematurely sent to Sentry by the Postgres query executor.

• Changed logger.error to logger.warn for QUERY_ERROR in src/integrations/postgres/shared.ts.
• This adjusts the severity level for logging Postgres query execution errors.

This fix was generated by Seer in Sentry, triggered by Owen. 👁️ Run ID: 10541230

Not quite right? Click here to continue debugging with Seer.

[barecheck]

Barecheck - Code coverage report

Total: 92.9%

Your code coverage diff: 0.15% ▴

Uncovered files and lines

File	Lines
src/integrations/postgres/shared.ts	100, 104-111

[Copilot]

Pull request overview

This PR changes the logging level for Postgres query execution errors from error to warn in response to a Sentry issue where admin query failures were being sent to Sentry despite being gracefully handled by the API.

Changes:

• Modified logging level from logger.error to logger.warn for the QUERY_ERROR event in the Postgres query executor

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

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.