feat: add favorite contexts#228
Conversation
- persist favorite context names in config alongside favorite services - group favorite contexts first in the picker without changing configured ordering - render favorite contexts with favorite styling and cover toggle behavior
|
Warning Review limit reached
More reviews will be available in 46 minutes and 14 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
WalkthroughAdds favorite-context support to the TUI context picker. The config schema gains ChangesFavorite Contexts Feature
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
There was a problem hiding this comment.
The favorite contexts implementation looks solid. The code follows established patterns from the existing favorite services feature, includes comprehensive test coverage, and properly handles edge cases like cursor positioning after favoriting. No blocking issues identified.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@internal/app/context_list.go`:
- Around line 64-80: The favorite toggle operation is not atomic because
in-memory state is modified before persisting to disk. If the
configSetFavoriteContextsFn call fails, the in-memory state (m.favoriteContexts
and m.cfg.FavoriteContexts) has already been changed while the file state
remains unchanged. Reorder the operations to persist to disk first by calling
configSetFavoriteContextsFn with the new favorites list before modifying
m.favoriteContexts and m.cfg.FavoriteContexts, ensuring that in-memory state
only changes if persistence succeeds.
In `@internal/app/screen_context_test.go`:
- Around line 107-187: Add a new test function following the pattern of
TestContextPickerFavoriteTogglePersists and
TestContextPickerFavoriteToggleSelectsNextContext to cover the error case where
configSetFavoriteContextsFn returns an error. In this test, stub
configSetFavoriteContextsFn to return a non-nil error, perform the favorite
toggle action (pressing 'f'), and then assert that the error is properly
captured in the model's error state (check the screenError field or equivalent),
that an appropriate error message is displayed, and that the favorite state in
the config and model remains unchanged, ensuring the error prevents the favorite
from being committed.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 39de31d7-2340-4a95-a3cc-74c6b604d045
📒 Files selected for processing (10)
README.mdinternal/app/app.gointernal/app/context_list.gointernal/app/context_table.gointernal/app/filter.gointernal/app/help.gointernal/app/screen_context.gointernal/app/screen_context_test.gointernal/config/config.gointernal/config/config_test.go
📜 Review details
🧰 Additional context used
📓 Path-based instructions (5)
**/*.go
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.go: Use lipgloss for styled TUI output — column-aligned tables with dimmed labels in Go implementation files
Implement scroll windowing with formula:visibleLines := max(m.height-N, 5)in Go TUI implementation
Files:
internal/app/context_list.gointernal/app/context_table.gointernal/app/app.gointernal/app/filter.gointernal/app/help.gointernal/app/screen_context.gointernal/app/screen_context_test.gointernal/config/config.gointernal/config/config_test.go
⚙️ CodeRabbit configuration file
**/*.go: For Go reviews, look beyond compilation and prioritize nil pointer risks,
context propagation, AWS SDK pagination, error wrapping, deterministic
sorting, and stable table/detail rendering. For new AWS service work,
verify that repository interfaces, model mapping, app integration, and
tests are updated together.
Files:
internal/app/context_list.gointernal/app/context_table.gointernal/app/app.gointernal/app/filter.gointernal/app/help.gointernal/app/screen_context.gointernal/app/screen_context_test.gointernal/config/config.gointernal/config/config_test.go
internal/app/**
⚙️ CodeRabbit configuration file
internal/app/**: For Bubble Tea screen changes, verify message routing, key handling,
filter target resets, height-based windowing, help text, and back/home
navigation against the existing screen patterns.
Files:
internal/app/context_list.gointernal/app/context_table.gointernal/app/app.gointernal/app/filter.gointernal/app/help.gointernal/app/screen_context.gointernal/app/screen_context_test.go
**
⚙️ CodeRabbit configuration file
**: # unic — RolesDeveloper
You — All implementation, code review, testing, and releases.
Advisor (Kiro)
Senior engineer role. Responsibilities:
- Architecture decisions and trade-off analysis
- Code review guidance when asked
- Debugging help and troubleshooting
- AWS SDK / API usage advice
- Bubbletea / TUI pattern recommendations
- Suggest approaches, never write code autonomously
Rule: Advisor does not write or modify code unless explicitly asked. All code is written by the developer.
Documentation Harness
When implementation changes affect user-visible behavior, config/auth behavior, service coverage, TUI flow, or contributor workflow:
- update
README.md- update the relevant file under
docs/- use
docs/documentation-harness.mdas the minimum checklistA feature change is not considered complete until the related docs are reviewed and updated when needed.
Branch Naming Harness
When creating a working branch for repository work, prefer the convention defined in
docs/branch-naming-harness.md.Expected format:
<work-type>/<issue-number>-<short-description>Examples:
feature/58-s3-browserbugfix/76-s3-region-error-handlingdocs/79-documentation-harnessWorktree Isolation Rule
All repository work must start from
mainin a fresh git worktree.
- Before editing files, fetch or otherwise verify the intended
mainbase.- Create a new worktree and branch from
mainororigin/main.- Do not implement new work directly in the primary checkout or on an existing
feature branch.- Keep one worktree per task, issue, or PR-sized change.
- If follow-up work appears to depend on another unmerged branch, still create a
fresh worktree frommainfirst, then explicitly document and apply the
dependency only when it is unavoidable.
Files:
internal/app/context_list.gointernal/app/context_table.gointernal/app/app.gointernal/app/filter.gointernal/app/help.gointernal/app/screen_context.gointernal/app/screen_context_test.goREADME.mdinternal/config/config.gointernal/config/config_test.go
**/*_test.go
📄 CodeRabbit inference engine (CLAUDE.md)
Tests use mock client interfaces (see
rds_test.gopattern) in Go test files
Files:
internal/app/screen_context_test.gointernal/config/config_test.go
⚙️ CodeRabbit configuration file
**/*_test.go: Check that tests cover API errors, mapping edge cases, and navigation
state transitions, not only happy paths. Prefer mock-based tests that do
not depend on external AWS calls.
Files:
internal/app/screen_context_test.gointernal/config/config_test.go
README.md
📄 CodeRabbit inference engine (CLAUDE.md)
README.md: When adding, modifying, or deleting features, always updateREADME.mdin parallel with code changes
UpdateCurrently Implemented Featurestable in README.md: add new services/features, update status changes (🚧→✅), remove deleted items
UpdateTUI Key Bindingstable in README.md when key bindings are added, changed, or deleted
UpdateUsagesection in README.md when new CLI commands or flags are added
UpdateConfigurationsection in README.md when configuration format changes
Files:
README.md
⚙️ CodeRabbit configuration file
README.md: Verify that README changes match actual CLI/TUI behavior and that
Currently Implemented Features, TUI Key Bindings, Usage, and
Configuration content stay aligned with code changes.
Files:
README.md
🔇 Additional comments (8)
internal/config/config.go (1)
39-40: LGTM!Also applies to: 90-91, 125-126, 211-212, 258-259, 275-299, 313-317, 329-330, 347-353, 674-701
internal/config/config_test.go (1)
114-136: LGTM!Also applies to: 185-222, 473-476, 500-502
internal/app/screen_context.go (1)
19-21: LGTM!Also applies to: 190-198, 336-343, 352-353
internal/app/help.go (1)
668-669: LGTM!README.md (1)
150-151: LGTM!Also applies to: 336-337, 363-367
internal/app/app.go (1)
174-174: LGTM!Also applies to: 231-235, 244-244
internal/app/filter.go (1)
176-176: LGTM!internal/app/context_table.go (1)
110-119: LGTM!
- persist favorite context changes before mutating model state - add regression coverage for favorite persistence failures
2 participants
Summary
Adds favorite context support to the context picker so users can pin frequently used AWS contexts the same way they can pin AWS services.
Related Issues
Closes #227
Validation
make testmake buildChecklist
docs/branch-naming-harness.mddocs/documentation-harness.md)docs/pages updated if architecture, auth, config, or workflow changedSummary by CodeRabbit
Release Notes
fkey in the context picker. Favorited contexts automatically sort to the top of the list for easier navigation. Favorite selections are saved to the configuration and persist across sessions.