Add scanner error reporting to Status API and UI #4094
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Introduced LastScanErrorKey constant for error tracking. - Updated StatusInfo struct to include LastError field. - Modified scanner logic to store and retrieve last scan error. - Enhanced ScanStatus response to include error information. - Updated UI components to display last scan error when applicable. - Added tests to verify last scan error functionality. Signed-off-by: Deluan <deluan@navidrome.org>
- Added LastScanTypeKey and LastScanStartTimeKey constants for tracking scan type and start time. - Updated StatusInfo struct to include ScanType and ElapsedTime fields. - Implemented getScanInfo method to retrieve scan type, elapsed time, and last error. - Modified scanner logic to store scan type and start time during scans. - Enhanced ScanStatus response and UI components to display scan type and elapsed time. - Added formatShortDuration utility for better elapsed time representation. - Updated activity reducer to handle new scan status fields. Signed-off-by: Deluan <deluan@navidrome.org>
- Removed the old controller_status_test.go file. - Merged relevant tests into the new controller_test.go file for better organization and maintainability. - Ensured all existing test cases for controller status are preserved and functional. Signed-off-by: Deluan <deluan@navidrome.org>
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed everything up to 227b503 in 1 minute and 46 seconds. Click for details.
- Reviewed
691lines of code in13files - Skipped
0files when reviewing. - Skipped posting
4draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. scanner/controller.go:121
- Draft comment:
Consider handling errors from property retrieval (e.g. time.Parse failures) rather than ignoring them to aid debugging. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
2. scanner/scanner.go:65
- Draft comment:
Avoid ignoring errors from Property.Put calls; consider handling or logging these errors for improved reliability. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a tricky case. On one hand, ignoring errors is generally bad practice. On the other hand, these Property.Put calls appear to be for tracking scan status/metadata, and the code seems to intentionally ignore these errors consistently throughout the file. The main scanning functionality would continue even if these properties fail to be stored. Looking at lines 190-199, when Property.Put errors actually matter, they ARE being handled properly. I might be wrong about the importance of these properties - perhaps failing to store the scan type or error state could cause issues elsewhere in the system. Also, consistently ignoring errors doesn't necessarily make it correct. The code shows a clear pattern of handling Property.Put errors when they are critical (like in runUpdateLibraries) and intentionally ignoring them for status tracking. This suggests the ignored errors are indeed non-critical by design. The comment should be deleted. The error handling appears to be intentional - critical Property.Put errors are handled while status tracking errors are consistently ignored.
3. ui/src/layout/ActivityPanel.jsx:80
- Draft comment:
Consider memoizing the triggerScan function (e.g. using useCallback) to optimize performance and avoid unnecessary re-renders. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
4. ui/src/utils/formatters.test.js:69
- Draft comment:
Typo: The test description reads "format dates". For consistency with other test descriptions, consider changing it to "formats dates". - Reason this comment was not posted:
Comment was on unchanged code.
Workflow ID: wflow_5eNbS89YCJLSJi6Y
You can customize 
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed c4b3a79 in 1 minute and 24 seconds. Click for details.
- Reviewed
13lines of code in1files - Skipped
0files when reviewing. - Skipped posting
1draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. scanner/controller.go:117
- Draft comment:
The updated comment is less descriptive. It would be clearer to mention that the function retrieves the last error, scan type, and start time (used to compute elapsed time) from the database properties. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is technically correct - the function does retrieve those specific fields. However, the new comment is also correct and follows the principle of abstraction by focusing on what the function does conceptually rather than implementation details. The suggested change doesn't point out any actual issues or improvements in the code itself. The comment is about documentation style rather than code quality. It's subjective whether more detailed comments are better - sometimes more abstract comments are preferable. While the suggestion is technically accurate, it doesn't highlight any real issues that need fixing. The new comment is sufficient for understanding the function's purpose. This comment should be deleted as it's purely about documentation style preferences rather than identifying actual code issues that need fixing.
Workflow ID: wflow_aqNleg8CxhXZUrQK
You can customize
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What's Changed
This PR adds the ability to track and display scanner errors in the UI. It includes:
Three new properties in the database to store scan-related information:
LastScanError: Stores the most recent scan error messageLastScanType: Tracks whether the last scan was "quick" or "full"LastScanStartTime: Captures when the scan started to calculate elapsed timeUpdated the scanner controller to track these properties and include them in status responses.
Enhanced the Activity Panel in the UI to show:
Screenshot
Changes