fix: resolve latest service version to manifest default#434
Conversation
|
Warning Review limit reached
Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?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 reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. 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, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughChangesService image default resolution
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
server/internal/orchestrator/swarm/manifest_loader.go (1)
418-428: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueReuse the already-instantiated
ServiceImagefor the fallback.Instead of recalculating the image tag and allocating a new
ServiceImagepointer when falling back to the last entry, you can track the last image during the loop and reuse it. This avoids repeating theserviceImageTagfunction call.♻️ Proposed refactor to track and reuse the last image
- var defaultImage *ServiceImage + var defaultImage, lastImage *ServiceImage for _, e := range s.entries { img := &ServiceImage{Tag: serviceImageTag(cfg, e.Image)} sv.addServiceImage(s.name, e.Version, img) if e.Default { defaultImage = img } + lastImage = img } - if defaultImage == nil && len(s.entries) > 0 { - defaultImage = &ServiceImage{Tag: serviceImageTag(cfg, s.entries[len(s.entries)-1].Image)} + if defaultImage == nil { + defaultImage = lastImage }🤖 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 `@server/internal/orchestrator/swarm/manifest_loader.go` around lines 418 - 428, Reuse the existing ServiceImage instance for the fallback in the service-entry loop. Track the image created for the latest entry while iterating over s.entries, then assign that tracked pointer to defaultImage when no explicit default exists and entries are present; remove the duplicate serviceImageTag call and allocation.
🤖 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 `@server/internal/orchestrator/swarm/manifest_loader.go`:
- Around line 418-428: Reuse the existing ServiceImage instance for the fallback
in the service-entry loop. Track the image created for the latest entry while
iterating over s.entries, then assign that tracked pointer to defaultImage when
no explicit default exists and entries are present; remove the duplicate
serviceImageTag call and allocation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 73562f47-fba3-463d-9dc8-680939cbc011
📒 Files selected for processing (1)
server/internal/orchestrator/swarm/manifest_loader.go
2 participants
Summary
This PR addresses an issue where service specifications using
"version": "latest"failed at runtime because"latest"was not registered in the manifest-backed version map.Changes
manifest_loader.go:buildServiceVersionsnow registers a"latest"alias for each service type (PostgREST, MCP, RAG) pointing to the
default: truemanifest entry, or the last entry if none is markedTesting
Verification:
Services with version - 1.0.0
Services with latest version
Checklist
PLAT-693