fix: Multiple query cancellation issue #3819
Conversation
WalkthroughRecent updates to the codebase include improvements in the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI as User Interface
participant RQL as RunningQueriesList Component
participant Logs as useLogs Composable
participant Server
User->>UI: Initiate delete query
UI->>RQL: Handle selectedRow & delete dialog
RQL-->>Server: Send delete request
RQL->>RQL: Reset selectedRow
RQL->>RQL: Hide deleteDialog (finally block)
RQL->>RQL: Reset deleteDialog data (finally block)
Server-->>RQL: Response received
User->>UI: Perform action causing error 429
UI->>Logs: Handle error response
Logs->>Logs: Check for error code 429
Logs->>Logs: Set notification message and update histogram error data
Warning Review ran into problemsProblems (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- web/src/components/queries/RunningQueriesList.vue (2 hunks)
Additional comments not posted (2)
web/src/components/queries/RunningQueriesList.vue (2)
511-512: Ensure consistent state management before fetching new data.Resetting
selectedRow.valuebefore callinggetRunningQueries()is a good practice as it ensures that no stale selections interfere with new data fetches.
532-532: Properly manage dialog visibility and data state in thefinallyblock.Moving the reset of
deleteDialog.value.showanddeleteDialog.value.datato thefinallyblock is a robust enhancement. This ensures that the dialog state is reset regardless of whetherdeleteQueryresolves or rejects, which is crucial for maintaining a consistent UI state.Also applies to: 532-532
| if (err?.response?.data?.code == 429) { | ||
| notificationMsg.value = err.response.data.message; | ||
| searchObj.data.histogram.errorMsg = err.response.data.message; | ||
| } |
There was a problem hiding this comment.
Handle HTTP error code 429 more gracefully.
The code correctly identifies and handles HTTP error code 429, which typically signifies too many requests. However, the current implementation directly assigns the error message to notificationMsg.value and searchObj.data.histogram.errorMsg. Consider implementing a backoff strategy or rate limiting to better manage request rates and enhance user experience.
- notificationMsg.value = err.response.data.message;
- searchObj.data.histogram.errorMsg = err.response.data.message;
+ // Implement backoff or rate limiting here
+ notificationMsg.value = "Too many requests, please try again later.";
+ searchObj.data.histogram.errorMsg = "Too many requests, please try again later.";Committable suggestion was skipped due to low confidence.
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Bug Fixes** - Improved handling of selected rows and delete dialog visibility in the Running Queries list. - Added better error handling for specific error code (429) in log operations, providing more informative notifications. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Bhargav <[email protected]>
2 participants
Summary by CodeRabbit