fix(pending-ops): record posted ids and land failed_partial instead of clean rejected after partial commits (#842) (#1110)

Multi-step executors (match_transaction_invoice, credit_invoice) post an
irreversible voucher or persist a credit note and then run later fallible
steps. A failure there previously marked the whole op status=rejected,
hiding the posted entity and its id from operators.

- new migration 20260722134114: add failed_partial to the
  pending_operations status CHECK and treat it as terminal in both
  immutability triggers (immutable, undeletable, never re-claimable)
- PartialCommitError + ExecutorResult.partialPostedIds carry the posted
  ids; the dispatcher writes status=failed_partial with
  result_data.posted_ids and returns code=partial_commit
- instrument only the two named executors; hoist the read-only
  settlement-account resolution above the storno in the match executor
- consumer sweep: status union + query schema widened, failed_partial
  folds into the Avvisade tab with a badge and posted-ids detail line,
  bulk/reject routes and MCP tools message it explicitly, worklist and
  expiry sweep intentionally untouched (not pending work)
- tests: pg-real coverage for the new terminal semantics, dispatcher unit
  tests for both partial paths plus byte-for-byte regression guards

Fixes #842

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Jakob Wennberg
2026-07-22 18:33:49 +02:00
committed by GitHub
co-authored by Claude Fable 5
parent 27ef398623
commit 3e1ea29d02
16 changed files with 795 additions and 23 deletions
+124 -10
View File
@@ -60,6 +60,7 @@ import {
type SkatteverketCommitServices,
type SkvSubmitResult,
} from '@/lib/pending-operations/skatteverket-commit'
import { PartialCommitError } from '@/lib/pending-operations/errors'
import { getEmailService } from '@/lib/email/service'
import { hasCapability, CAPABILITY_BLOCKED_MESSAGE_SV } from '@/lib/entitlements/has-capability'
import { PAID_OPERATION_CAPABILITY_MAP } from '@/lib/entitlements/keys'
@@ -192,7 +193,16 @@ async function recordSkippedInvoiceJournalEntry(
// ── Executors ────────────────────────────────────────────────────
type ExecutorResult = { data?: Record<string, unknown>; error?: string; status?: number }
type ExecutorResult = {
data?: Record<string, unknown>
error?: string
status?: number
// Set when the executor already performed an irreversible side-effect
// (posted voucher, persisted credit note) before the failure in `error`:
// the dispatcher then lands the op in 'failed_partial' instead of
// 'rejected' and persists these ids in result_data.posted_ids (issue #842).
partialPostedIds?: Record<string, string>
}
async function commitCategorizeTransaction(
supabase: SupabaseClient,
@@ -1722,13 +1732,13 @@ async function commitMatchTransactionInvoice(
}
const { newPaidAmount, newRemaining, isFullyPaid, newStatus } = payment.plan
if (transaction.journal_entry_id) {
await reverseEntry(supabase, companyId, userId, transaction.journal_entry_id)
await supabase.from('transactions').update({ journal_entry_id: null }).eq('id', transactionId)
}
const now = new Date().toISOString()
// Read-only prevalidation, deliberately hoisted ABOVE the irreversible
// storno below (issue #842): resolveSettlementAccount can throw
// (BookkeepingDatabaseError on a failed cash_accounts lookup), and a throw
// here must reject the op with NOTHING posted. Behavior-preserving on the
// happy path: these are pure reads.
const { data: settings } = await supabase
.from('company_settings').select('accounting_method, entity_type').eq('company_id', companyId).single()
@@ -1746,6 +1756,17 @@ async function commitMatchTransactionInvoice(
// transaction settled into. Mirrors the match-invoice route fix.
const paymentAccount = await resolveSettlementAccount(supabase, companyId, transaction.cash_account_id, log)
// From here on the executor posts irreversible vouchers. Track their ids so
// a later failure can land the op in 'failed_partial' carrying them
// (issue #842) instead of a clean-looking 'rejected'.
const postedIds: Record<string, string> = {}
if (transaction.journal_entry_id) {
const reversal = await reverseEntry(supabase, companyId, userId, transaction.journal_entry_id)
postedIds.reversal_journal_entry_id = reversal.id
await supabase.from('transactions').update({ journal_entry_id: null }).eq('id', transactionId)
}
let journalEntryId: string | null = null
try {
if (useCashEntry) {
@@ -1762,9 +1783,26 @@ async function commitMatchTransactionInvoice(
journalEntryId = je?.id ?? null
}
} catch (err) {
if (isBookkeepingError(err)) throw err
// Recoverable: the dispatcher releases the op back to 'pending' and this
// executor is re-entrant past the storno (the transaction was unlinked
// above, so a retry does not post a second storno). Keep that path even
// when a reversal voucher was already posted.
if (err instanceof AccountsNotInChartError) throw err
if (isBookkeepingError(err)) {
// A reversal voucher already posted makes this a partial commit, not a
// clean failure: surface the storno id (issue #842).
if (Object.keys(postedIds).length > 0) {
throw new PartialCommitError(
`match_transaction_invoice failed after posting a reversal voucher: ${err instanceof Error ? err.message : 'journal entry creation failed'}`,
postedIds,
err,
)
}
throw err
}
log.error('Failed to create match journal entry:', err)
}
if (journalEntryId) postedIds.payment_journal_entry_id = journalEntryId
const { data: updatedRows, error: updateInvError } = await supabase
.from('invoices')
@@ -1778,9 +1816,19 @@ async function commitMatchTransactionInvoice(
.in('status', ['sent', 'overdue', 'partially_paid'])
.select('id')
if (updateInvError) return { error: 'Failed to update invoice status', status: 500 }
if (updateInvError) {
return {
error: 'Failed to update invoice status',
status: 500,
...(Object.keys(postedIds).length > 0 ? { partialPostedIds: postedIds } : {}),
}
}
if (!updatedRows || updatedRows.length === 0) {
return { error: 'Invoice has already been fully paid or is no longer matchable', status: 409 }
return {
error: 'Invoice has already been fully paid or is no longer matchable',
status: 409,
...(Object.keys(postedIds).length > 0 ? { partialPostedIds: postedIds } : {}),
}
}
const paymentNotes = (accountingMethod === 'cash' && !isFullyPaid)
@@ -3034,7 +3082,19 @@ async function commitCreditInvoice(
.eq('id', creditNote.id)
}
} catch (err) {
if (isBookkeepingError(err)) throw err
if (isBookkeepingError(err)) {
// The credit note row and the original's 'credited' flip are already
// persisted: a clean 'rejected' would hide them. Land the op in
// 'failed_partial' carrying the ids (issue #842). This intentionally
// covers AccountsNotInChartError too: the release-to-pending retry
// path cannot recover a credit_invoice op (re-running the executor
// auto-rejects with 409 because the original is already 'credited').
throw new PartialCommitError(
`credit_invoice failed after persisting the credit note: ${err instanceof Error ? err.message : 'journal entry creation failed'}`,
{ credit_note_id: creditNote.id, original_invoice_id: id },
err,
)
}
log.error('Failed to create credit note journal entry:', err)
}
@@ -4615,6 +4675,30 @@ async function commitPendingOperationInner(
}
}
} catch (err) {
// Partial commit (issue #842): the executor already posted an
// irreversible side-effect (storno voucher, credit note) before a later
// step failed. 'rejected' would misrepresent reality and hide the posted
// entity, so land the op in the terminal 'failed_partial' status with the
// posted ids in result_data so an operator can locate the orphan. Checked
// FIRST: a wrapped recoverable cause must NOT release the claim back to
// 'pending' (the side-effect already exists).
if (err instanceof PartialCommitError) {
await supabase
.from('pending_operations')
.update({
status: 'failed_partial',
resolved_at: new Date().toISOString(),
result_data: { error: err.message, threw: true, posted_ids: err.postedIds },
})
.eq('id', pendingOp.id)
return {
status: 'failed',
error: err.message,
http_status: 500,
code: 'partial_commit',
data: { posted_ids: err.postedIds },
}
}
// Accounts-not-in-chart is RECOVERABLE: the booking itself is valid; the
// company's chart just lacks the (standard BAS) accounts it posts to. Do
// NOT consume the op: release the atomic claim back to 'pending' so the
@@ -4670,6 +4754,36 @@ async function commitPendingOperationInner(
}
if (result.error) {
// Structured partial marker (issue #842): same semantics as the
// PartialCommitError branch above, for executors that report the failure
// via the ExecutorResult contract instead of throwing. Must run before
// the auto-reject branch: a 409 AFTER a voucher was posted is a partial
// commit, not a re-stageable rejection.
const partialPostedIds =
result.partialPostedIds && Object.keys(result.partialPostedIds).length > 0
? result.partialPostedIds
: null
if (partialPostedIds) {
await supabase
.from('pending_operations')
.update({
status: 'failed_partial',
resolved_at: new Date().toISOString(),
result_data: {
error: result.error,
http_status: result.status,
posted_ids: partialPostedIds,
},
})
.eq('id', pendingOp.id)
return {
status: 'failed',
error: result.error,
http_status: result.status ?? 500,
code: 'partial_commit',
data: { posted_ids: partialPostedIds },
}
}
const isAutoReject = result.status === 404 || result.status === 409
await supabase
.from('pending_operations')