[cristim]

What

With RequireDifferentApprover on, the creator of an RI exchange could approve and execute it themselves. Neither branch of approveRIExchange (session or email token) called requireDifferentApprover, which only the purchase approval paths used.

• requireDifferentApprover now takes (subjectID, creatorUserID *string) instead of a *config.PurchaseExecution, so the RI exchange path reuses the same policy. Purchase behaviour is unchanged (separate refactor commit).
• approveRIExchangeViaSession and approveRIExchangeViaToken both run the check after authorization and before the pending -> processing transition. The token branch resolves the caller's session and fails closed (500) when the mode is on and no session resolves, matching approveViaToken for purchases.
• The token branch matters on its own: a 403 from the session branch falls through to the token branch when a token is in the URL, so a session-only fix is bypassable (the mutation run below shows this).

Nil creator (decision left open)

Every RI exchange written today comes from the automated pipeline (exchange.auto via configExchangeStoreAdapter, which never sets CreatedByUserID), so production exchange rows all have a NULL creator. The purchase policy denies a NULL creator with 403. Applying that here would make every RI exchange unapprovable while 4-eyes is on, the same failure #233 describes for scheduler-created purchases. This PR therefore leaves creator-less exchanges approvable as before and pins that in a test. What 4-eyes should do for creator-less rows is the open question in #233.

How verified

Toolchain: GOTOOLCHAIN=go1.26.6 GOWORK=off GOFLAGS='-p=2 -count=1' AWS_EC2_METADATA_DISABLED=true

• New TestApproveRIExchange_FourEyes (9 subtests). With the RI exchange change reverted (helper refactor kept), 5 fail and 4 pass:

  --- FAIL: TestApproveRIExchange_FourEyes/session:_creator_with_approve-own_denied
  --- FAIL: TestApproveRIExchange_FourEyes/session:_admin_creator_denied
  --- FAIL: TestApproveRIExchange_FourEyes/session:_creator_holding_the_email_token_still_denied
  --- FAIL: TestApproveRIExchange_FourEyes/token:_creator_session_without_approve_rights_denied
  --- FAIL: TestApproveRIExchange_FourEyes/token:_no_session_fails_closed
  Error: An error is expected but got nil.
  

• Mutation, session call removed: the 3 session: denial subtests fail. Token call removed: creator_holding_the_email_token, token: creator session and token: no session fail. Nil-creator skip removed: automated exchange without creator stays approvable fails.
• With the fix: go build ./..., go vet and go vet -tags integration on internal/api, internal/purchase and internal/server are clean. go test passes for all three packages (2445 tests in internal/api). golangci-lint run ./internal/api/... reports no issues.
• Frontend: handleRIExchangeApproveClick in frontend/src/riexchange.ts shows the backend error string in a toast, so the creator sees "Failed to approve exchange: approval declined: 4-eyes mode requires a different approver than the requester".

Deliberately not in this PR

• The 4-eyes policy for exchanges with no creator (fix(purchase): scheduler-created executions have no creator and cannot pass four-eyes #233).
• authorizeSessionApproveRIExchange does not check the session's account scope (a separate finding).
• canApproveRIExchangeRow in riexchange.ts still shows the Approve button to the creator under 4-eyes. It is a UX gate only; the backend now refuses the approval.
• sec(api): approve/cancel discard an authorization denial and fall through — safe only by coincidence #173 (discarded authorization denial) and sec(money): currency is dropped at every layer boundary, so USD-denominated caps are compared against non-USD amounts [platform part] #361 ("USD" literal), which are in the same file.

Refs #221 (production exchange rows have no creator recorded, so the control only applies to rows that carry one; see "Nil creator")

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{This review includes 4 billable files and costs up to $1.00.}

• Ask an admin to make reviews automatic

Open in CodeRabbit

Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing.

Or wait 4 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used all 2 included reviews currently available. Your 54 included PR review attempts over the past 7 days set your current allowance at 2 reviews per hour.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository: LeanerCloud/cloud-commitments-platform/.coderabbit.yaml
• Review profile: CHILL
• Plan: Essentials
• Run ID: 76e9ba18-b6c9-46cb-b49d-8163e6a82238

📥 Commits

Reviewing files that changed from the base of the PR and between da5da2b and a01bb1a.

📒 Files selected for processing (4)

• internal/api/handler_purchases.go
• internal/api/handler_purchases_test.go
• internal/api/handler_ri_exchange.go
• internal/api/handler_ri_exchange_test.go

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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