StaticinstanceThe process service, starting runs on the queue the temporal namespace names.
Read b2b.bank_transaction_reconcile_queue_view.
The two filters that justify reading the view rather than
BankTransactionService.search are CustomerAttribution and
feedSources: ownership lives behind the view's LATERAL join and
feed_source is raw ->> 'source', and the base-table search can express
neither.
OptionalbankIds?: string[]OptionalcustomerAttribution?: CustomerAttributionDefaults to "REQUIRED". See CustomerAttribution.
OptionalcustomerIds?: string[]OptionalfeedSources?: NonNullable<BankTransactionRawSource | null>[]Optionalids?: string[]OptionalorderBy?: DbOrderByCriterion<Optionalpage?: number1-based; defaults to 1.
OptionalpageSize?: numberDefaults to 50.
OptionalpostedAt?: DbTimestampCriteriaWindow on when the BANK posted, not when CFX wrote the row.
Optionaltypes?: ("CREDIT" | "DEBIT")[]Hand each id to the reconciliation workflow, reporting what happened to every one.
Reads the rows' current status first rather than starting blind: a row that
has since been reconciled needs no run, and an id that names nothing would
start a workflow whose only possible end is a non-retryable
BANK_TRANSACTION_NOT_FOUND failure sitting in the run list. Both are
reported instead, as is a row on a CFX_OPERATING account, which the
workflow could only mint or burn against.
A start that throws is not caught. Temporal being unreachable is a non-functional failure, and swallowing it would report a backfill that did not happen; the whole call is safe to retry because every start is keyed on the bank transaction id.
Selecting stranded
bank_transactionrows and handing them to the reconciliation workflow.Reconciliation is started by whoever writes the row, so a row that was already in the table when the workflow shipped has never been offered to it — and never will be.
filterAlreadySeenVictorTransactionsmakes the Victor sync skip rows that already exist, so re-syncing does not reach them either. This service is the only path that does.The admin dashboard's reconcile queue is its one caller. Selection policy, the batch cap and the per-id outcome vocabulary live here.
Every operation is idempotent.
startReconciliationre-reads each row's status first and skips the ones already RECONCILED, the workflow itself short-circuits onALREADY_RECONCILED, and the run is keyed on the bank transaction id — so running it twice costs a read and starts nothing new.