Repository navigation
test(purchase): cover ApproveAndExecute refusal of an EC2 retry successor - #928
Merged
Merged
Conversation
…ssor Drive aws ec2/compute/redshift/data-warehouse retry successors (RetryAttemptN = 1, status pending) through both approval entry points: the email-link token path (ApproveExecution -> ApproveAndExecute with no session UUID) and the session path (ApproveAndExecute with transitionedBy). Each must buy nothing, return the refusal, and be persisted failed with the operator action. An aws/rds retry successor on the same paths is the positive control and must buy exactly once. Closes LeanerCloud#780 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
Warning Review limit reached
This review includes 1 billable file and costs up to $0.25. Or wait 59 minutes for your next included review. View limit details
Comment |
cristim
reviewed
Oct 16, 2026
cristim
left a comment
Member
There was a problem hiding this comment.
Independent review of 4625bfe: draft: blocks ready
Findings
- NIT (non-blocking): internal/purchase/aws_no_token_redrive_test.go:194-197. #780 asks for one ApproveAndExecute case; the PR adds token (ApproveExecution) and session (ApproveAndExecute) paths x 4 EC2/Redshift slugs plus an rds positive control. That is a superset of the acceptance criteria and is fine. The PR title says only ApproveAndExecute while the test also covers ApproveExecution; wording only.
- NIT / follow-up: DirectExecute, RunPlannedPurchaseNow and fireOneDue (EC2 case) still have no EC2 retry-successor test. All reach the same executeAndFinalize funnel (internal/purchase/approvals.go:425, manager.go:255), so this is structural coverage, and #780 does not ask for them.
What I attacked
- Real path: the test goes ApproveExecution/ApproveAndExecute -> enforceFourEyesPolicy -> claimRunning (mocked store CAS, asserted with .Once() and the expected transitionedBy) -> executeAndFinalize -> preExecutionRefusal -> armedRedriveRefusal. Only the store, email and provider are mocked; no code between the entry point and preExecutionRefusal is stubbed.
- No-purchase assertion: yes, rec.count()==0 on the PurchaseCommitment mock for every refused row; the rds control buys exactly once through the same harness, so the zero is not a harness artifact. It also asserts the error text, final saved status "failed" and the operator reason.
- Mutation probe 1: disabled armedRedriveRefusal in preExecutionRefusal (manager.go:293). All 8 refused subtests FAIL; both rds controls still pass. Reverted.
- Approval-path-only bypass: not possible without editing the shared funnel, since the refusal exists only in executeAndFinalize and both approve paths call it at approvals.go:425. Probe 1 covers it.
- go test ./internal/purchase/...: 706 passed.
- #780 acceptance: pending EC2 retry successor approved via ApproveAndExecute buys nothing and persists failed with the refusal reason. Met.
Gate status
- Independent review: this comment, against the SHA above.
- Findings resolved: none actionable.
- CI on SHA: pending at review time (checks queued/in progress); must be green.
- Labels: PR carries triaged, priority/p3, severity/low, urgency/eventually, impact/few, effort/xs, type/bug, which mirror #780.
- Local real-path evidence: above (macOS, mocked store/provider, fail-before via mutation). Not on the PR body yet.
- No CodeRabbit threads.
Blocks ready
- Take the PR out of draft (contributor-owned).
- CI green on this SHA.
- Record this verdict and local verification evidence on the PR (done by this comment); any new commit restarts the gate.
Member
|
Gate record for 4625bfe (origin/main CLAUDE.md "Review gate"):
Marking ready (owner-authorized) and merging at 4625bfe with --match-head-commit. |
cristim
marked this pull request as ready for review
October 16, 2026 02:40
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Test-only change. Adds
TestApproveAndExecuteRefusesAWSNoTokenRetrySuccessortointernal/purchase/aws_no_token_redrive_test.go. Before this, the EC2/Redshift retry-successor refusal from #778 (MON-02) was tested only through SQSProcessMessage. The approval entry points reach the sameexecuteAndFinalize->preExecutionRefusal->armedRedriveRefusalfunnel, but no EC2 test called them.Closes #780
What the test covers
For each AWS slug that dispatches to the EC2 or Redshift client (
ec2,compute,redshift,data-warehouse), a retry successor (RetryAttemptN = 1, statuspending) goes through both ways an operator approves a row:ApproveExecutionwith a valid approval token. It callsApproveAndExecute(..., transitionedBy=nil).ApproveAndExecutewith the session user's UUID astransitionedBy. This is whatapprovePurchaseViaSessionininternal/apidoes.The test asserts:
PurchaseCommitmentcallsrefusing to execute retry attempt 1)failed, and its error carries the operator action (Check EC2 Reserved Instances or Redshift Reserved Nodes)transitionedBy(store.AssertExpectations)Positive control: an
aws/rdsretry successor goes through the same harness and both paths and must buy exactly once. Without it, a zero count could mean the harness never reached the provider, and a guard that refused every AWS service would also pass.Does the refusal actually work?
Yes. The new test passes on current main without any code change. No fix was needed.
Verification
Unit tests with mocks only (testify mocks for the store, provider factory and service client). No real AWS calls.
gocyclo: no non-test Go files changed.
AWS_CONFIG_FILE/AWS_SHARED_CREDENTIALS_FILEare set to/dev/nullonly because the local machine's default AWS profile is invalid.Mutation evidence (this test is the guard, so "fail before" means "fails when the guard is broken")
Each mutation was applied to
internal/purchase/manager.go, the new test was run, and then the file was restored withgit checkout:armedRedriveRefusal(exec)call inpreExecutionRefusalarmedRedriveRefusalalways returns nilrecRedriveRefusalReasonnever refuses (if false && awsPurchaseHasNoDuplicateGuard(...))if true || ...)token/rdsandsession/rdspositive controls; refused subtests passCoverage gaps
fireOneDue(scheduled delayed-approval path) for EC2 is not added here. It goes through the sameexecuteAndFinalizefunnel and is covered for Azure byTestFireScheduledDelayedPurchasesRefusesArmedAzureSavingsPlanRetry. The issue's expected behavior and proposed fix name onlyApproveAndExecute. Happy to add it if wanted.DirectExecuteandRunPlannedPurchaseNowsharetransitionApproveAndExecutewithApproveAndExecutebut are not driven separately.Labels
Could a maintainer please copy the issue's triage labels onto this PR:
triaged,priority/p3,severity/low,urgency/eventually,impact/few,effort/xs,type/bug.🤖 Generated with Claude Code