Improve container parsing code quality#1217
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthrough
Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
lib/data/provider/container.dart (1)
72-85: 🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy liftDo not clear
isBusywhile an old refresh may still be running.Line 80 can bypass the
refresh()guard after a type switch, allowing an older suspended refresh to resume and overwrite state for the new container type. Use a refresh generation/cancellation token, or otherwise ignore stale refresh completions aftersetType.🤖 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 `@lib/data/provider/container.dart` around lines 72 - 85, The setType flow in ContainerProvider is clearing isBusy too early, which can let an older suspended refresh resume after a type switch and overwrite the new state. Update setType and refresh to use a generation/token or similar stale-refresh guard, and only apply refresh results when they still match the latest ContainerType change. Make sure refresh completions from an older request are ignored after setType starts a new cycle.
🤖 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.
Outside diff comments:
In `@lib/data/provider/container.dart`:
- Around line 72-85: The setType flow in ContainerProvider is clearing isBusy
too early, which can let an older suspended refresh resume after a type switch
and overwrite the new state. Update setType and refresh to use a
generation/token or similar stale-refresh guard, and only apply refresh results
when they still match the latest ContainerType change. Make sure refresh
completions from an older request are ignored after setType starts a new cycle.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 5ee31879-dfba-45eb-a6f0-e9e8d9eae8d5
📒 Files selected for processing (2)
lib/data/model/container/ps.dartlib/data/provider/container.dart
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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.
Inline comments:
In `@lib/data/provider/container.dart`:
- Around line 121-128: The cached sudo probe is being reused across target
changes, so refreshes can keep a stale needSudo result after switching
endpoints. In the container provider’s refresh flow and the Docker-host save
path, make sure the cached sudo state is invalidated whenever the
target/endpoint changes before calling refresh(), and let _requiresSudo
recompute against the new target instead of reusing the old sudoCompleter
result. Use the existing refresh(), sudoCompleter, and _requiresSudo symbols to
locate the cache/reset logic and update it so a new endpoint always triggers a
fresh sudo probe.
- Around line 268-270: The Docker header filtering in the container listing
logic is too broad because `removeWhere((element) => element.contains('CONTAINER
ID'))` can حذف valid rows that merely contain that text. Update the
`ContainerType.docker` branch in the container parsing flow to remove only the
actual `ps` header row, using a precise header match or a positional/header
check instead of substring matching so real container entries are preserved.
- Around line 121-122: The refresh flow in ContainerProvider.refresh() is
dropping completion refreshes when state.isBusy is true, which can leave the
view stale after run() finishes. Update refresh() to queue a pending refresh
instead of returning immediately during an in-flight auto-refresh, and have
run() trigger that queued refresh once the busy operation completes. Use the
existing refresh() and run() methods in ContainerProvider to add the deferral
logic without changing the external API.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: d7b5a0eb-9b2f-4836-a5b7-5e7e71720e28
📒 Files selected for processing (1)
lib/data/provider/container.dart
Summary by CodeRabbit
DOCKER_HOSTto handle special characters correctly.