refactor: Migrate Machine online-repair handler to WithTx#564
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
Summary by CodeRabbit
WalkthroughThe PR refactors the online machine repair logic in UpdateMachineHandler from explicit transaction control to the cdb.WithTx helper pattern. Both enable and disable paths now execute Temporal health report override workflows synchronously, with symmetric label management and timeout-aware error handling. ChangesOnline Repair Transaction & Workflow Integration
🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
🔐 TruffleHog Secret Scan✅ No secrets or credentials found! Your code has been scanned for 700+ types of secrets and credentials. All clear! 🎉 🕐 Last updated: 2026-05-21 20:18:09 UTC | Commit: adc2229 |
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 `@api/pkg/api/handler/machine.go`:
- Around line 1524-1530: The response is being built from stale data because the
handler reassigns um = machine after the DB update; remove the assignment "um =
machine" in the transaction completion block (the one checking timeoutResp and
err) so that any in-memory updates applied to um (e.g., label or maintenance
changes) are preserved; rely on the existing fallback "if um == nil { um =
machine }" to cover the online-repair-only case and keep the existing error
handling via common.HandleTxError.
🪄 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: CHILL
Plan: Enterprise
Run ID: daedffd7-3dde-440c-831c-3c66674a219b
📒 Files selected for processing (1)
api/pkg/api/handler/machine.go
Picks up the last `BeginTx` site left in `machine.go`, which is the new the online-repair flow that was recently added. Callouts are: - Uses `WithTx` (not `WithTxResult`) — `um` is set after success and `timeoutResp` already pulls toward `WithTx`. - Both inner branches (enable + disable) apply `timeoutResp` with their respective literal workflow names. - The `iDAO.GetAll` instance fetch stays inside the tx since it drives the status-mutation decision. No new advisory lock -- matches the existing maintenance-mode handler nearby. - The handler triggers a workflow (either `CreateMachineHealthReportOverride` or `DeleteMachineHealthReportOverride` depending on enable/disable) and waits on `we.Get`, so it's also adopting what now seems like our `timeoutResp` pattern. - Errors switched to `NewAPIError`. Signed-off-by: Chet Nichols III <chetn@nvidia.com>
adc2229 to
e328d84
Compare
🔍 Container Scan Summary
Per-CVE detail lives in the per-service |
Description
Picks up the last
BeginTxsite left inmachine.go, which is the new the online-repair flow that was recently added.Callouts are:
WithTx(notWithTxResult) —umis set after success andtimeoutRespalready pulls towardWithTx.timeoutRespwith their respective literal workflow names.iDAO.GetAllinstance fetch stays inside the tx since it drives the status-mutation decision. No new advisory lock -- matches the existing maintenance-mode handler nearby.CreateMachineHealthReportOverrideorDeleteMachineHealthReportOverridedepending on enable/disable) and waits onwe.Get, so it's also adopting what now seems like ourtimeoutResppattern.NewAPIError.Signed-off-by: Chet Nichols III chetn@nvidia.com
Type of Change
Services Affected
Related Issues (Optional)
Breaking Changes
Testing
Additional Notes