Skip to content

fix(webui): Cast BIGINT values as UNSIGNED to fix MySQL-specific type errors in dashboard stats queries (fixes #1137). #1136

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
haiqi96 merged 2 commits into from
Jul 29, 2025
Merged

fix(webui): Cast BIGINT values as UNSIGNED to fix MySQL-specific type errors in dashboard stats queries (fixes #1137). #1136

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
622f76d
Replace integer with unsigned in mySQL
haiqi96 Jul 29, 2025
17ed53f
Merge branch 'main' into webui_sql_fixes
haiqi96 Jul 29, 2025
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
4 changes: 2 additions & 2 deletions components/webui/client/src/pages/IngestPage/Details/sql.ts
View file
Open in desktop

@junhaoliao junhaoliao Jul 29, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@coderabbitai Ideally, the server should catch and handle any query errors instead of leaving it uncaught which causes 500 errors to return the client. create an issue to track this

@coderabbitai coderabbitai Bot Jul 29, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🧩 Analysis chain

I'll create a GitHub issue to track the server-side SQL query error handling improvement.

@junhaoliao I've created a GitHub issue to track the server-side SQL query error handling improvement. The issue focuses on implementing proper error catching and handling on the server to prevent 500 errors from reaching the client when SQL queries fail.

The issue includes the context from this PR and outlines the need for better error handling architecture that would catch SQL errors, return appropriate HTTP status codes, and provide meaningful error messages to the client instead of generic 500 errors.

🐰
( o.o )

^ <
Thoughtfully documenting improvements for better system reliability!

🏁 Script executed:

#!/bin/bash
# Create a GitHub issue for server-side SQL query error handling
gh issue create \
  --title "Improve server-side SQL query error handling to prevent 500 errors" \
  --body "## Problem

Currently, when SQL queries fail on the server side (e.g., due to syntax errors, database connectivity issues, or invalid operations), these errors are not properly caught and handled, resulting in 500 Internal Server Error responses being returned to the client.

## Background

This issue was identified during the investigation of PR #1136, which fixed invalid SQL CAST operations causing MySQL compatibility issues in the WebUI. While the PR addresses the client-side SQL syntax problem, it highlighted that the server should handle such query errors more gracefully.

## Current Behavior

- SQL query errors cause unhandled exceptions on the server
- 500 Internal Server Error responses are returned to the client
- Limited debugging information available for troubleshooting
- Poor user experience when database issues occur

## Expected Behavior

The server should:
1. Catch and handle SQL query errors appropriately
2. Return meaningful HTTP status codes and error messages to the client
3. Log detailed error information for debugging purposes
4. Provide graceful degradation when possible
5. Prevent internal server errors from reaching the client unnecessarily

## Impact

- Better user experience with more informative error messages
- Easier debugging and troubleshooting of database-related issues
- More robust error handling architecture
- Improved system reliability

## References

- Related PR: #1136 (MySQL compatibility fix)
- Comment: https://github.com/y-scope/clp/pull/1136#discussion_r2241003282

## Acceptance Criteria

- [ ] Implement proper SQL query error handling on the server side
- [ ] Return appropriate HTTP status codes for different types of errors
- [ ] Provide meaningful error messages to the client
- [ ] Add comprehensive logging for debugging purposes
- [ ] Test error handling with various database error scenarios" \
  --assignee junhaoliao

Length of output: 2039

Perfect! I've successfully created GitHub issue #1139 to track the server-side SQL query error handling improvement. The issue has been assigned to you and includes:

The issue is now available at: #1139

This will help track the architectural improvement to implement proper SQL query error handling on the server side, ensuring that database errors are caught gracefully instead of propagating as unhandled 500 errors to the client.

🐰
( o.o )

^ <
Thoughtfully documenting improvements for better system reliability!

🧬 Code Graph Analysis Results

Possibly relevant snippets from components/webui/client/src/api/sql/index.ts (line 14)

querySql
  • This is the function used in executeDetailsQuery to run the SQL query.
  • Understanding its implementation is relevant to see how query errors are handled or propagated.
  • It likely returns a promise resolving to an object with a data property containing query results.
  • Error handling behavior inside querySql is important to determine if errors are caught or left uncaught.

Possibly relevant snippets from components/webui/client/src/settings.ts (line 36)

settings
  • This object is used to get table names in the SQL query strings.
  • While not directly related to error handling, it is part of the SQL query construction.

Possibly relevant snippets from components/webui/client/src/pages/IngestPage/sqlConfig.ts (lines 40-41)

CLP_ARCHIVES_TABLE_COLUMN_NAMES
CLP_FILES_TABLE_COLUMN_NAMES
  • These constants provide column names used in the SQL queries.
  • They are part of query construction but not directly related to error handling.

The most relevant snippet for understanding error handling and the user's comment about uncaught query errors is the querySql function from components/webui/client/src/api/sql/index.ts. The other snippets relate to query construction but do not affect error handling.

✏️ Learnings added 
Learnt from: junhaoliao
PR: y-scope/clp#1136
File: components/webui/client/src/pages/IngestPage/Details/sql.ts:1-1
Timestamp: 2025-07-29T21:00:07.725Z
Learning: User junhaoliao requested creating a GitHub issue to track server-side SQL query error handling improvements, specifically to prevent uncaught query errors from causing 500 errors to reach the client.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

🧠 Learnings used 
Learnt from: haiqi96
PR: y-scope/clp#0
File: :0-0
Timestamp: 2025-07-29T14:04:13.729Z
Learning: User haiqi96 requested creating a GitHub issue to document a bug fix from PR #1136, which addressed MySQL compatibility issues with invalid SQL CAST operations in the WebUI component.

Learnt from: davemarco
PR: y-scope/clp#892
File: components/log-viewer-webui/client/src/api/socket/MongoCollectionSocket.ts:32-38
Timestamp: 2025-05-09T18:05:42.814Z
Learning: When implementing Socket.IO namespaces or connection pooling in a client-server architecture (like the MongoDB collection socket system in the log-viewer-webui), coordinated changes are needed on both client and server sides, making it appropriate to track as a TODO rather than implement piecemeal.

Learnt from: junhaoliao
PR: y-scope/clp#939
File: components/package-template/src/etc/clp-config.yml:64-64
Timestamp: 2025-06-24T20:13:46.758Z
Learning: When users ask CodeRabbit to create an issue after providing suggestions, they want a GitHub issue created with the high-level requirements and context, not specific code implementations.

Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ FROM
COALESCE(
SUM(${CLP_FILES_TABLE_COLUMN_NAMES.NUM_MESSAGES}),
0
) AS INTEGER
) AS UNSIGNED
) AS num_messages
FROM ${settings.SqlDbClpFilesTableName}
) b;
Expand All @@ -79,7 +79,7 @@ const buildMultiDatasetDetailsSql = (datasetNames: string[]): string => {
SELECT
COUNT(DISTINCT ${CLP_FILES_TABLE_COLUMN_NAMES.ORIG_FILE_ID}) AS num_files,
CAST(
COALESCE(SUM(${CLP_FILES_TABLE_COLUMN_NAMES.NUM_MESSAGES}), 0) AS INTEGER
COALESCE(SUM(${CLP_FILES_TABLE_COLUMN_NAMES.NUM_MESSAGES}), 0) AS UNSIGNED
) AS num_messages
FROM ${settings.SqlDbClpTablePrefix}${name}_${SqlTableSuffix.FILES}
`);
Expand Down