Conversation
📝 WalkthroughWalkthroughThis PR introduces support for a new Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 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 |
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)
internal/config/containers.go (1)
100-107:⚠️ Potential issue | 🟡 MinorPotential orphaned container issue for users who previously configured
tag="stable".If any users had manually set
tag="stable"before this change, their existing containers would be namedlocalstack-aws-stable. After this update,Name()returnslocalstack-awsfortag="stable", causing:
stopcommand to miss the running container (seeinternal/container/stop.go:20-30)IsRunningchecks to not find the container (seeinternal/container/running.go:11-17)- Removal to target wrong container name (see
internal/container/start.go:239-241)Consider documenting this edge case or adding a migration note for users to manually clean up any
localstack-aws-stablecontainers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/config/containers.go` around lines 100 - 107, Existing containers named with tag="stable" (e.g., localstack-<type>-stable) will be orphaned because ContainerConfig.Name() now omits "stable"; update the container lookup/stop/is-running/remove logic to fall back to the legacy name when a container is not found: after attempting the new name from ContainerConfig.Name(), also check "localstack-<type>-stable" (and treat it as the same instance) in the routines that stop containers, check IsRunning, and remove/start cleanup (the code areas that call ContainerConfig.Name() for lookup); alternatively add a brief migration note in docs telling users to manually remove any localstack-<type>-stable containers if you prefer not to change runtime lookup behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@internal/config/containers.go`:
- Around line 100-107: Existing containers named with tag="stable" (e.g.,
localstack-<type>-stable) will be orphaned because ContainerConfig.Name() now
omits "stable"; update the container lookup/stop/is-running/remove logic to fall
back to the legacy name when a container is not found: after attempting the new
name from ContainerConfig.Name(), also check "localstack-<type>-stable" (and
treat it as the same instance) in the routines that stop containers, check
IsRunning, and remove/start cleanup (the code areas that call
ContainerConfig.Name() for lookup); alternatively add a brief migration note in
docs telling users to manually remove any localstack-<type>-stable containers if
you prefer not to change runtime lookup behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 458c888a-3bb7-4e9e-bc2e-653b73a9b255
📒 Files selected for processing (6)
README.mdinternal/config/config.gointernal/config/containers.gointernal/config/default_config.tomlinternal/container/start.gotest/integration/version_resolution_test.go
|
Can we please convert to draft and not merge this until we made a call about the semantic of the |
|
Closing for now, will reopen if necessary |
From now on, we set "stable" tag on config.toml by default.
Validation for "stable" tag license is similar to "latest" tag.
Current default tag
latestwas causing UX issues, because it was frequently pulling the newest dev version from latest, so using stable will improve that situation.Limitation: We're not changing "latest" with "stable" for customers that have lstk already, even if they update. The users can change it manually.
Towards DRG-663