Skip to content

fix(aws/opensearch): validate RI count before idempotency short-circuit (follow-up to #831) - #1460

Merged
cristim merged 1 commit into
mainfrom
fix/831-followup-opensearch-count-validation
Jul 19, 2026
Merged

cristim merged 1 commit into
mainfrom
fix/831-followup-opensearch-count-validation

Conversation

@cristim

@cristim cristim commented Jul 19, 2026

Copy link
Copy Markdown
Member

Follow-up to #831 (refs #250) — unaddressed CodeRabbit threads

Part of the adversarial-sweep over recently-merged PRs. #831 merged with two unresolved CodeRabbit threads.

F1 (Major) — invalid count bypasses validation via idempotency short-circuit

PurchaseCommitment ran safeInt32Count after the idempotency guard, so a re-drive carrying an invalid instance count (negative / int32-overflow / zero) against an already-existing reservation would short-circuit to Success and never surface the bad input. Moved count validation to the boundary — immediately after result init, before findOfferingID and the idempotency guard.

F2 (Minor) — tag-failure log test under-asserts

The OPENSEARCH_TAG_FAILED structured-log test asserted only the sentinel + commitment_id; it now asserts the error= field carries the underlying cause (a line missing the error would have passed before).

Verification

  • New TestClient_PurchaseCommitment_InvalidCount_FailsBeforeIdempotencyGuard: verified it fails on the pre-fix ordering (returns Success via short-circuit) and passes after the reorder; asserts the offering lookup + reservation describe are never reached.
  • TestClient_PurchaseCommitment_OfferingNotFound now sets a valid Count=1 (it previously relied on Count=0 reaching the offering lookup).
  • go build ./..., go vet, full opensearch package (55 tests) green.

…it (follow-up to #831)

PurchaseCommitment ran safeInt32Count after the idempotency guard, so a re-drive
carrying an invalid instance count (negative / int32-overflow / zero) against an
already-existing reservation would short-circuit to Success and never surface the
bad input. Move the count validation to the boundary -- immediately after result
init, before findOfferingID and the idempotency guard -- so invalid counts fail
loud regardless of idempotency state (addresses the unresolved CodeRabbit Major
thread on #831).

Also harden the tag-failure structured-log test to assert the error= field
carries the underlying cause, not just the OPENSEARCH_TAG_FAILED sentinel and
commitment_id (unresolved CodeRabbit Minor thread on #831).

Tests:
- New TestClient_PurchaseCommitment_InvalidCount_FailsBeforeIdempotencyGuard:
  verified it FAILS on the pre-fix ordering (returns Success via short-circuit)
  and PASSES after the reorder; asserts the offering lookup and reservation
  describe are never reached.
- TestClient_PurchaseCommitment_OfferingNotFound now sets a valid Count=1 (it
  previously relied on Count=0 being tolerated up to the offering lookup).
@cristim cristim added triaged Item has been triaged priority/p2 Backlog-worthy severity/medium Moderate harm urgency/this-sprint Within the current sprint impact/few Limited audience effort/s Hours type/bug Defect labels Jul 19, 2026
@cristim

cristim commented Jul 19, 2026

Copy link
Copy Markdown
Member Author

@coderabbitai review

@coderabbitai

coderabbitai Bot commented Jul 19, 2026 •

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 4 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: bc061d42-abe5-49f0-a6ca-4ba77ff7538c

📥 Commits

Reviewing files that changed from the base of the PR and between 5c267c5 and 3234126.

📒 Files selected for processing (2)
  • providers/aws/services/opensearch/client.go
  • providers/aws/services/opensearch/client_test.go
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/831-followup-opensearch-count-validation

Comment @coderabbitai help to get the list of available commands.

@coderabbitai

coderabbitai Bot commented Jul 19, 2026 •

Copy link
Copy Markdown
Contributor
✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@cristim
cristim merged commit eb442e8 into main Jul 19, 2026
19 checks passed
@cristim
cristim deleted the fix/831-followup-opensearch-count-validation branch July 27, 2026 11:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

effort/s Hours impact/few Limited audience priority/p2 Backlog-worthy severity/medium Moderate harm triaged Item has been triaged type/bug Defect urgency/this-sprint Within the current sprint

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant