feat: add available_upgrades opt-in to databases API#415
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughAdds an optional ChangesAvailable Upgrades via
Poem
🚥 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 |
|
@coderabbitai review |
Up to standards ✅🟢 Issues
|
| Category | Results |
|---|---|
| Complexity | 1 medium |
🟢 Metrics 23 complexity · 0 duplication
Metric Results Complexity 23 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.
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@server/internal/api/apiv1/post_init_handlers.go`:
- Around line 291-294: The code silently ignores errors from
ds.ParsePgEdgeVersion() when checking for available upgrades, causing the
available_upgrades field to disappear from the API response even when explicitly
requested. Fix this by adding structured error logging (using zerolog) in the
else block when the parse error occurs, ensuring you include database
identifiers in the log message for debugging context, and optionally map the
error to an appropriate Goa HTTP error if strict validation is desired. Apply
this fix to both occurrences mentioned: the main occurrence around line 291-294
and the second occurrence around line 359-362 in the same file.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 905db74f-ea87-40ec-a4f0-fac40b1b7a8f
⛔ Files ignored due to path filters (15)
api/apiv1/gen/control_plane/client.gois excluded by!**/gen/**api/apiv1/gen/control_plane/endpoints.gois excluded by!**/gen/**api/apiv1/gen/control_plane/service.gois excluded by!**/gen/**api/apiv1/gen/http/cli/control_plane/cli.gois excluded by!**/gen/**api/apiv1/gen/http/control_plane/client/cli.gois excluded by!**/gen/**api/apiv1/gen/http/control_plane/client/client.gois excluded by!**/gen/**api/apiv1/gen/http/control_plane/client/encode_decode.gois excluded by!**/gen/**api/apiv1/gen/http/control_plane/client/types.gois excluded by!**/gen/**api/apiv1/gen/http/control_plane/server/encode_decode.gois excluded by!**/gen/**api/apiv1/gen/http/control_plane/server/server.gois excluded by!**/gen/**api/apiv1/gen/http/control_plane/server/types.gois excluded by!**/gen/**api/apiv1/gen/http/openapi.jsonis excluded by!**/gen/**api/apiv1/gen/http/openapi.yamlis excluded by!**/gen/**api/apiv1/gen/http/openapi3.jsonis excluded by!**/gen/**api/apiv1/gen/http/openapi3.yamlis excluded by!**/gen/**
📒 Files selected for processing (13)
api/apiv1/design/api.goapi/apiv1/design/database.goclient/single.goserver/internal/api/apiv1/convert.goserver/internal/api/apiv1/post_init_handlers.goserver/internal/api/apiv1/pre_init_handlers.goserver/internal/database/orchestrator.goserver/internal/database/service.goserver/internal/orchestrator/swarm/available_upgrades_test.goserver/internal/orchestrator/swarm/images.goserver/internal/orchestrator/swarm/manifest_loader.goserver/internal/orchestrator/swarm/orchestrator.goserver/internal/orchestrator/systemd/orchestrator.go
| if includesAvailableUpgrades(req.Include) { | ||
| if version, err := ds.ParsePgEdgeVersion(db.Spec.PostgresVersion, db.Spec.SpockVersion); err == nil { | ||
| apiDB.AvailableUpgrades = availableUpgradesToAPI(s.dbSvc.AvailableUpgrades(version)) | ||
| } |
There was a problem hiding this comment.
Avoid silently dropping requested available_upgrades on parse failures.
Line 292 and Line 360 ignore ds.ParsePgEdgeVersion errors, which makes available_upgrades silently disappear for malformed stored versions even when explicitly requested. Please at least emit structured error/warn logs with database identifiers (or map to a Goa error if you want strict behavior).
As per coding guidelines, server/internal/**/*.go should use structured error logging with zerolog and map domain-specific errors to HTTP status codes via Goa.
Also applies to: 359-362
🤖 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/api/apiv1/post_init_handlers.go` around lines 291 - 294, The
code silently ignores errors from ds.ParsePgEdgeVersion() when checking for
available upgrades, causing the available_upgrades field to disappear from the
API response even when explicitly requested. Fix this by adding structured error
logging (using zerolog) in the else block when the parse error occurs, ensuring
you include database identifiers in the log message for debugging context, and
optionally map the error to an appropriate Goa HTTP error if strict validation
is desired. Apply this fix to both occurrences mentioned: the main occurrence
around line 291-294 and the second occurrence around line 359-362 in the same
file.
Source: Coding guidelines
1 participant
Summary
This PR adds support for the optional
?include=available_upgradesquery parameter toGET /v1/databases/{id}andGET /v1/databases. When specified, the response includes anavailable_upgradesfield for each database, listing newer stable manifest versions available within the same(postgres_major, spock_major)compatibility bucket as the database's current version.Changes
orchestrator/swarm/images.go: AddedStabilityfield toImagesstruct; addedAvailableUpgrades()method to*Versionsthat scans the manifest for newer stable entries in the same(postgres_major, spock_major)bucket usingds.Version.Compareorchestrator/swarm/manifest_loader.go:buildVersionsnow propagatesStabilityfrom manifest JSON intoImages.Stabilitydatabase/orchestrator.go: AddedAvailableUpgradestruct andAvailableUpgradesmethod to theOrchestratorinterfaceorchestrator/swarm/orchestrator.go: ImplementsAvailableUpgradesdelegating too.versionsorchestrator/systemd/orchestrator.go: No-opAvailableUpgradesreturningnildatabase/service.go: ExposesAvailableUpgradesso handlers don't need direct orchestrator accessapi/apiv1/design/api.go+database.go: AddedAvailableUpgradeGoa type,available_upgradesfield onDatabase/DatabaseSummary,includequery param on both endpoints; regenerated API layerapi/apiv1/post_init_handlers.go: Computes and setsavailable_upgradeswheninclude=available_upgradesis presentapi/apiv1/convert.go: AddedincludesAvailableUpgradesandavailableUpgradesToAPIhelpersclient/single.go: Passes empty payload toListDatabases— client interface unchangedTesting
Verification:
cp1-req create-database < ../demo/Images/create_db_for_upgrade.jsonavailable_upgradesmust beChecklist
PLAT-602