fix(refund): block new refund while a prior refund's accounting is unresolved (scjz.22)#346
Conversation
…resolved (scjz.22) A refund whose accounting staging failed (accountingRetryRequired) may not have written its cost-layer snapshot, so its quantity counts toward the refund qty cap while NOT reducing shipment cost availability — a second refund can then be under qty-budget yet over-draw the cost basis and throw spuriously (qty cap and COGS-basis reduction read divergent state). Block a genuinely-new refund while any prior refund on the order has accountingRetryRequired; the operator/sweep must resolve the prior refund's accounting first, restoring a consistent source of truth. Idempotent replays returned earlier. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d77892c28b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // retryRefundAccounting, or automatically by the accounting-sync sweep) keeps the | ||
| // two sources consistent. Idempotent replays of an existing refund returned earlier, | ||
| // so this only blocks genuinely-new refunds. | ||
| if (existingRefunds.some((refund) => refund.accountingRetryRequired)) { |
There was a problem hiding this comment.
This guard only checks accountingRetryRequired, which remains false for a just-created refund until the later post-transaction stageRefundAccountingReversals call either succeeds or catches and marks the row for retry. Because the advisory/order locks are released before that staging work runs, a second refund started in that window sees the prior refund but passes this check; if the first staging then fails before writing cost-layer snapshots, the original qty-vs-cost-basis divergence can still occur. Consider marking the refund as accounting-pending before releasing the create transaction, or otherwise blocking on in-progress/missing prior refund cost snapshots as well as retry-required rows.
Useful? React with 👍 / 👎.
1 participant
Problem
A refund whose accounting staging failed (
accountingRetryRequired) may not have written its cost-layer snapshot, so its quantity counts toward the refund qty cap while NOT reducing shipment cost availability. A second refund can then be under qty-budget yet over-draw the cost basis and throw spuriously — the qty cap and COGS-basis reduction read divergent state.Fix
Block a genuinely-new refund while any prior refund on the order has
accountingRetryRequired. The prior refund's accounting must be retried first (manually viaretryRefundAccountingor automatically by the accounting-sync sweep), which restores a consistent source of truth and subsumes the divergence. Idempotent replays of an existing refund return earlier, so they're unaffected.🤖 Generated with Claude Code