Fix manual Bangumi rescrape search hang#33
Conversation
📝 WalkthroughWalkthroughManual Bangumi metadata match search in AnimeDetailViewModel now runs under a per-query timeout via withTimeout, with try/catch/finally handling distinguishing success, timeout, cancellation, and general error cases. The search context construction was simplified, and tests were updated with a shared factory and a new failure-path test. ChangesManual Match Search Rework
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
ui-tv/src/main/kotlin/com/miruplay/tv/ui/detail/AnimeDetailViewModel.kt (1)
210-214: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider logging the timeout before swallowing it.
The
TimeoutCancellationExceptionis handled purely by updatingstatusMessage, so no diagnostic trace is emitted when a manual search hangs — which is exactly the failure mode this PR targets. Awarn-level log (includingqueries.sizeand the computed timeout) would make future hang investigations far easier without changing behavior.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@ui-tv/src/main/kotlin/com/miruplay/tv/ui/detail/AnimeDetailViewModel.kt` around lines 210 - 214, In AnimeDetailViewModel’s manual search timeout handling, the TimeoutCancellationException is being swallowed after only updating _manualMatch, so add a warn-level log in the catch block before returning. Include the relevant context from the search flow, especially queries.size and the computed timeout used by the search, so hangs can be diagnosed later without changing behavior.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@ui-tv/src/main/kotlin/com/miruplay/tv/ui/detail/AnimeDetailViewModel.kt`:
- Around line 210-214: In AnimeDetailViewModel’s manual search timeout handling,
the TimeoutCancellationException is being swallowed after only updating
_manualMatch, so add a warn-level log in the catch block before returning.
Include the relevant context from the search flow, especially queries.size and
the computed timeout used by the search, so hangs can be diagnosed later without
changing behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: bc96a35f-3003-4941-b301-02cc5b2468db
📒 Files selected for processing (2)
ui-tv/src/main/kotlin/com/miruplay/tv/ui/detail/AnimeDetailViewModel.ktui-tv/src/test/kotlin/com/miruplay/tv/ui/detail/AnimeDetailViewModelTest.kt
016c19b to
0e6e5bc
Compare
Summary
Root Cause
The rescrape dialog does not load the ONNX filename parser. It goes through
AnimeDetailViewModel.searchManualMatches()->AnimeMetadataSearchAggregator-> Bangumi archive/API. The old flow expanded selected keywords into up to 10 planner queries and did not reset busy state if aggregation failed or stalled. AniList had also been wired into the anime aggregation path, but anime matching should be Bangumi-only.Validation
./gradlew --stop./gradlew :core:model:clean :repository-api:test --tests com.miruplay.tv.repository.MetadataBatchPlannerTest --tests com.miruplay.tv.repository.MetadataSearchAggregationTest./gradlew :ui-tv:testDebugUnitTest --tests com.miruplay.tv.ui.detail.AnimeDetailViewModelTest./gradlew :app:assembleDebugNote: the first validation run hit the known Kotlin incremental cache
EOFException; stopping Gradle and cleaning:core:modelfixed it.Version
Patch-level bug fix. Current release line is
0.8.x(v0.8.544latest), andbaseAppVersionNamealready matches0.8.0, so no version bump.