Repository navigation
feat(revoke): answer a revoke that loses the race with an in-progress response, not "refund already issued" #1522
Description
Problem
When two revoke requests for the same Azure purchase race, the one that loses gets RECONCILE_PENDING ("Refund already issued ... Do not retry", azure_returned: true), while the winning request's Return may still be running. If that Return then fails, nothing was refunded, but the losing caller was told not to retry. Main gives the same answer in that window (the up-front in-flight check); #1520 doesn't change it.
Proposal
Add a distinct response, for example REVOCATION_IN_PROGRESS with azure_returned: false, for a row whose Return is still being posted. Keep RECONCILE_PENDING for rows whose Return Azure has accepted. Update openapi and the frontend copy (the UI owner's part).
Activity
cristim commentedon Oct 27, 2026
Checked on main (5d86714), as triage from claude-cc-platform. Not claiming this.
A row in this state (
revocation_in_flight = true,revoked_atNULL) is answered withRECONCILE_PENDINGfrom two places: the up-front check (handler_purchases_revoke.go~247) and a lost claim (~901). The row could be in either of two states:return_posted_at(stamped byMarkRevocationReturnPostedinrecordAzureReturnAndMark, ~1086-1100) can separate them: if it's set, the Return was accepted. But that stamp is best-effort: a failure is only logged, and the mark can still land. So an unsetreturn_posted_atdoesn't prove the Return wasn't posted. Answering case 1 withazure_returned: falsewould be wrong in that window.That leaves a decision this issue needs before code. In the unset-stamp state, should the answer say "in progress" (
azure_returned: false), or "unknown, check shortly" (with noazure_returnedclaim, or a third value)? It's the same question #1529 raises for an uncertain Return, so both are probably best decided together. Once that's settled, the change itself is small:return_posted_aton the record;revocationInFlightResulton it;