/** * @pwngh/economy-lab * * Copyright (c) Preston Neal * * This source code is licensed under the MIT license found in the * LICENSE.md file in the root directory of this source tree. * * @license MIT */ import type { WorkerCtx } from '../contract.js'; import type { Store } from '../ports.js'; /** * Result of one accrual-drain run (config.accrualDrain; the sweep is a no-op with the flag off). * - `drained`: one entry per seller whose claimed rows settled — how much reached `earned` and * how much repaid RECEIVABLE, in minor units. * - `failed`: that seller's transaction threw and rolled back; the rows stay pending for the * next run. */ export type AccrualDrainSummary = { drained: ReadonlyArray<{ sellerId: string; txnId: string; earnedMinor: string; recoveredMinor: string; }>; failed: ReadonlyArray<{ sellerId: string; code: string; }>; skipped: boolean; }; /** * Move parked seller shares from the SETTLEMENT_ACCRUAL shards to each seller's earned balance, * one posting per seller per run — the batching that makes the drain, not each purchase, the only * writer of earned rows. Negative rows (refund-recovery debt) net against the seller's positive * shares first: RECEIVABLE is repaid before new money reaches `earned`. Each seller drains in its * own transaction, so one poisoned group dead-ends alone and the rest still settle. `limit` * bounds both dimensions — sellers per run and rows per seller — so one run touches at most * limit-squared rows. * * The posting id derives from the claimed row set, so a crash between post and mark re-runs to * the same outcome: the replay finds the posting already committed and only re-applies the marks. * A drain can deadlock a concurrent refund of the same rows (opposite row/account lock order); * the engines classify that as transient and retry, and the loser re-reads the rows' new status. */ export declare function drainAccruals(store: Store, ctx: WorkerCtx, input: { now: number; limit: number; }): Promise;