feat: instance record management improvements#289
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (4)
📒 Files selected for processing (13)
💤 Files with no reviewable changes (2)
🚧 Files skipped from review as they are similar to previous changes (5)
📝 WalkthroughWalkthroughThe PR adds a "deleting" instance state throughout the API, client, and database layers, and refactors the instance cleanup workflow. It introduces Changes
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ 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 |
2ba6cc0 to
1aa1b8b
Compare
db5226b to
674a998
Compare
1aa1b8b to
06352a5
Compare
cf89c8a to
4cfbac6
Compare
06352a5 to
21bd381
Compare
4cfbac6 to
de78f91
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
🧹 Nitpick comments (2)
server/internal/database/instance_resource.go (1)
113-115: Add clarifying comment toDeletemethod explaining intentional no-op design.The
Deletemethod'snilreturn is intentional—instance record cleanup is handled byDeleteDbEntitiesactivity in the deletion workflow, not by the resource'sDeletemethod. Both deletion paths (normal workflow viaapplyPlansand host removal error handling) correctly converge ondatabase.Service.DeleteDatabase, which explicitly cleans up instance records.However,
InstanceResource.Deletelacks an explanatory comment. Other resource types with similar no-opDeletemethods (MCPConfigResource,ServiceInstanceSpecResource) include comments explaining why deletion is a no-op. Add a similar comment here for consistency and clarity.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/internal/database/instance_resource.go` around lines 113 - 115, Add a clarifying comment above the InstanceResource.Delete method stating that the nil return is intentional because instance record cleanup is handled by the DeleteDbEntities activity in the deletion workflow (both normal applyPlans workflow and host-removal error handling converge on database.Service.DeleteDatabase), mirroring the explanatory comments present on MCPConfigResource and ServiceInstanceSpecResource to make the no-op explicit and avoid confusion.server/internal/workflows/common.go (1)
94-125: Early exit optimization doesn't break outer loop.The inner loop
breakon line 104 only exits the innerfor _, event := range phaseloop, not the outerfor _, phase := range planloop. This means if an instance-modifying event is found in the first phase, the code still continues iterating through remaining phases unnecessarily.Consider adding a labeled break or restructuring for efficiency:
♻️ Optional: Use labeled break for efficiency
func (w *Workflows) updatePlannedInstanceStates( ctx workflow.Context, databaseID string, plan resource.Plan, ) error { var modifiesInstances bool +outer: for _, phase := range plan { for _, event := range phase { if event.Resource.Identifier.Type == database.ResourceTypeInstance { modifiesInstances = true - break + break outer } } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/internal/workflows/common.go` around lines 94 - 125, The loop in updatePlannedInstanceStates uses a break that only exits the inner "for _, event := range phase" loop, so modifiesInstances remains set but the outer "for _, phase := range plan" continues iterating; change the logic to stop scanning remaining phases as soon as an instance-modifying event is found — e.g., use a labeled break from the outer loop or immediately set modifiesInstances = true and break out of the outer loop (or return early) so you avoid unnecessary work before constructing UpdatePlannedInstanceStatesInput and calling ExecuteUpdatePlannedInstanceStates.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@server/internal/database/instance_resource.go`:
- Around line 113-115: Add a clarifying comment above the
InstanceResource.Delete method stating that the nil return is intentional
because instance record cleanup is handled by the DeleteDbEntities activity in
the deletion workflow (both normal applyPlans workflow and host-removal error
handling converge on database.Service.DeleteDatabase), mirroring the explanatory
comments present on MCPConfigResource and ServiceInstanceSpecResource to make
the no-op explicit and avoid confusion.
In `@server/internal/workflows/common.go`:
- Around line 94-125: The loop in updatePlannedInstanceStates uses a break that
only exits the inner "for _, event := range phase" loop, so modifiesInstances
remains set but the outer "for _, phase := range plan" continues iterating;
change the logic to stop scanning remaining phases as soon as an
instance-modifying event is found — e.g., use a labeled break from the outer
loop or immediately set modifiesInstances = true and break out of the outer loop
(or return early) so you avoid unnecessary work before constructing
UpdatePlannedInstanceStatesInput and calling ExecuteUpdatePlannedInstanceStates.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7c52a6ff-dac2-42db-b57b-60d005a5deec
⛔ Files ignored due to path filters (4)
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/instance.goclient/enums.goserver/internal/database/instance.goserver/internal/database/instance_resource.goserver/internal/database/instance_status_store.goserver/internal/database/instance_store.goserver/internal/database/service.goserver/internal/workflows/activities/activities.goserver/internal/workflows/activities/cleanup_instance.goserver/internal/workflows/activities/update_db_state.goserver/internal/workflows/activities/update_planned_instance_states.goserver/internal/workflows/common.goserver/internal/workflows/restart_instance.go
💤 Files with no reviewable changes (2)
- server/internal/workflows/restart_instance.go
- server/internal/workflows/activities/cleanup_instance.go
21bd381 to
2d6598c
Compare
6ac6ac9 to
584efda
Compare
rshoemaker
left a comment
There was a problem hiding this comment.
Looks good - one question in-line.
584efda to
a145735
Compare
Previously, the instance resource was responsible for creating, updating and deleting the instance record in Etcd. This led to a corner case in our disaster recovery process when we need to remove an instance resource without executing its lifecyce methods. This commit shifts the responsibility for creating and deleting the instance records to the workflows. Now, we will create or update the instance record to indicate the operation we're about to perform. We only completely delete the instance records if the database operation was successful. The instance resource still updates the instance record to indicate an available or failed status with an error. PLAT-398
a145735 to
f3db136
Compare
Summary
Previously, the instance resource was responsible for creating, updating and deleting the instance record in Etcd. This led to a corner case in our disaster recovery process when we need to remove an instance resource without executing its lifecyce methods.
This commit shifts the responsibility for creating and deleting the instance records to the workflows. Now, we will create or update the instance record to indicate the operation we're about to perform. We only completely delete the instance records if the database operation was successful.
The instance resource still updates the instance record to indicate an available or failed status with an error.
Testing
This is mostly a refactor to pave the way for other features, so the user-facing changes in this PR are very subtle. There's a new
deletinginstance state, and instances will enter acreating,modifying, ordeletingstate slightly earlier in the process than they used to.PLAT-398