fix: cr crd update on concurrency#825
Conversation
📝 WalkthroughWalkthroughThis PR adds input validation and retry logic to the commitment change handler. Requests without an Availability Zone are rejected with HTTP 400 before processing. CommittedResource upsert now uses retry-on-conflict semantics with generation capture for watch polling, removing prior immutability validation on the availability zone field. ChangesCommitment Change Handling
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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.
🧹 Nitpick comments (1)
internal/scheduling/reservations/commitments/api/change_commitments.go (1)
265-289: ⚡ Quick winAdd a regression test for the conflict-retry path.
This retry wrapper is the main behavior change in the PR, but the new tests only cover AZ validation. A test client that forces one conflict during the
CommittedResourcewrite would lock in both the retry behavior and the post-retry generation capture.🤖 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 `@internal/scheduling/reservations/commitments/api/change_commitments.go` around lines 265 - 289, Add a regression test that exercises the RetryOnConflict path by simulating a conflict on the first CommittedResource write and succeeding on retry, verifying that controllerutil.CreateOrUpdate is retried and that crGeneration is captured and appended to toWatch; specifically create a test around the function/path that uses retry.RetryOnConflict and controllerutil.CreateOrUpdate (or the higher-level change_commitments logic) where a fake client returns a Conflict error once for the initial Update, then succeeds, assert that applyCRSpec is applied, the code retries, cr.Generation is read into crGeneration, and a crWatch entry (name + generation) is appended (reference symbols: retry.RetryOnConflict, controllerutil.CreateOrUpdate, crGeneration, toWatch/crWatch, applyCRSpec).
🤖 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 `@internal/scheduling/reservations/commitments/api/change_commitments.go`:
- Around line 265-289: Add a regression test that exercises the RetryOnConflict
path by simulating a conflict on the first CommittedResource write and
succeeding on retry, verifying that controllerutil.CreateOrUpdate is retried and
that crGeneration is captured and appended to toWatch; specifically create a
test around the function/path that uses retry.RetryOnConflict and
controllerutil.CreateOrUpdate (or the higher-level change_commitments logic)
where a fake client returns a Conflict error once for the initial Update, then
succeeds, assert that applyCRSpec is applied, the code retries, cr.Generation is
read into crGeneration, and a crWatch entry (name + generation) is appended
(reference symbols: retry.RetryOnConflict, controllerutil.CreateOrUpdate,
crGeneration, toWatch/crWatch, applyCRSpec).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: bb2f3309-4e77-414f-b800-1692ca9b4d1b
📒 Files selected for processing (2)
internal/scheduling/reservations/commitments/api/change_commitments.gointernal/scheduling/reservations/commitments/api/change_commitments_test.go
Test Coverage ReportTest Coverage 📊: 69.0% |
No description provided.