@nehorai/credits 1.7.0 → 2.0.0

package/dist/repository/index.d.cts

@@ -1,6 +1,60 @@
-import { I as ICreditRepository, d as CreditBalanceUpdate, T as TierUpdateInput, a as CreateReservationInput, A as AddCreditsAtomicOptions, b as CreateTransactionInput, c as CreateUsageLogInput, U as UsageLogQuery, C as CreateJournalEntryInput, J as JournalEntryQuery } from '../types-DFe5BoJY.cjs';
-export { e as CreditRepositoryFactory, t as toClientUserCredits } from '../types-DFe5BoJY.cjs';
-import { b as PortableUserCredits, S as SubscriptionTier, c as PortableReservation, R as ReservationStatus, P as PortableTransaction, d as PortableUsageLog, f as PortableJournalEntry, M as MonthlyResetResult, e as SubscriptionExpiryResult } from '../types-CjLj3GW5.cjs';
+import { I as ICreditRepository, b as AddCreditsV2Input, a as AddCreditsOutcome, l as ReservationTransitionOptions, C as CommitOutcome, R as ReleaseOutcome, m as ReserveCreditsV2Input, n as ReserveOutcome, g as CreditBalanceUpdate, o as TierUpdateInput, d as CreateReservationInput, i as ExpireReservationV2Options, E as ExpireOutcome, A as AddCreditsAtomicOptions, e as CreateTransactionInput, f as CreateUsageLogInput, U as UsageLogQuery, c as CreateJournalEntryInput, J as JournalEntryQuery } from '../types-C8hZMe8a.cjs';
+export { h as CreditRepositoryFactory, j as ICreditRepositoryCreditsV2, k as ICreditRepositoryV2, s as reservationJournalKey, t as supportsCreditsV2, u as supportsIdempotentCredit, v as toClientUserCredits } from '../types-C8hZMe8a.cjs';
+import { c as PortableUserCredits, S as SubscriptionTier, a as PortableReservation, R as ReservationStatus, P as PortableTransaction, d as PortableUsageLog, f as PortableJournalEntry, M as MonthlyResetResult, e as SubscriptionExpiryResult } from '../types-DJ8yqaVr.cjs';
+
+/**
+ * One reservation flow for both repository generations.
+ *
+ * Adapters that implement the V2 boundary get the idempotent, race-safe path
+ * and own their journal entry. Adapters that do not (Firestore, custom
+ * implementations) keep the legacy read-then-write path, with the service
+ * writing the journal exactly as it always did — so upgrading this package
+ * does not change their behaviour, and does not double-write anyone's ledger.
+ */
+
+/**
+ * Reserve credits through V2 when available.
+ *
+ * A legacy adapter cannot honour an idempotency key — it has no unique index
+ * to enforce it — so asking for one there is a caller error rather than a
+ * silently ignored option.
+ */
+declare function reserveThroughRepository(repository: ICreditRepository, input: ReserveCreditsV2Input): Promise<ReserveOutcome>;
+/**
+ * Commit through V2 when available, else the legacy read-then-write path.
+ *
+ * **The legacy path cannot promise a single winner.** It reads the status and
+ * then writes, with no lock and no compare-and-set between the two, so two
+ * concurrent commits of the same reservation can both observe `reserved` and
+ * both proceed. The typed outcome still describes what *this* call saw, but on
+ * a legacy adapter `committed` means "this call did the work", not "this call
+ * was the only one that did". Callers needing exactly-once must use a
+ * repository for which `supportsCreditsV2` returns `true`.
+ */
+declare function commitThroughRepository(repository: ICreditRepository, userId: string, reservationId: string, options?: ReservationTransitionOptions): Promise<CommitOutcome>;
+/**
+ * Release through V2 when available, else the legacy read-then-write path.
+ *
+ * Same caveat as {@link commitThroughRepository}: on a legacy adapter the
+ * read-then-write sequence is unguarded, so `released` does not exclude a
+ * concurrent commit having also run. Only V2 repositories serialise the two.
+ */
+declare function releaseThroughRepository(repository: ICreditRepository, userId: string, reservationId: string, options?: ReservationTransitionOptions): Promise<ReleaseOutcome>;
+/**
+ * Credit an account through the idempotent path when the adapter has one.
+ *
+ * A legacy adapter cannot resolve `created` / `replayed` / `conflict`: it has
+ * no global unique index over `payment_ref`, so it cannot tell a re-delivered
+ * webhook from a second, genuinely different payment that reuses a reference.
+ * Rather than invent an outcome, this reports `created` — which is what the
+ * legacy method actually did — and the ambiguity is documented on the return
+ * type instead of hidden inside it.
+ *
+ * The reference is normalised here as well as in the adapters, so a legacy
+ * adapter that stores the raw string does not persist a whitespace-only
+ * reference that would then deduplicate nothing.
+ */
+declare function addCreditsThroughRepository(repository: ICreditRepository, input: AddCreditsV2Input): Promise<AddCreditsOutcome>;
 
 /**
  * Shared utilities for credit repository implementations
@@ -36,41 +90,103 @@ declare function getNextMonthlyReset(from?: Date): Date;
  * - Reference implementation for custom repositories
  */
 
-/**
- * In-Memory implementation of ICreditRepository
- *
- * Implements all repository methods using Map-based storage.
- * Useful for testing and as a reference implementation.
- */
 declare class InMemoryCreditRepository implements ICreditRepository {
-    private users;
-    private reservations;
-    private transactions;
-    private usageLogs;
-    private journalEntries;
+    private readonly store;
+    /**
+     * A copy, never the live record.
+     *
+     * Handing out the stored object made this adapter behave unlike any real
+     * one: a caller holding a "before" snapshot saw it mutate under them. The
+     * service's monthly reset compared `resetResult.credits.balance` against the
+     * balance it had read moments earlier, got zero because both were the same
+     * object, and silently skipped the reset's journal entry — while the SQL
+     * adapter, which maps each row into a fresh object, wrote it.
+     */
     getUserCredits(userId: string): Promise<PortableUserCredits | null>;
     initializeUserCredits(userId: string, tier: SubscriptionTier, initialBalance: number): Promise<PortableUserCredits>;
+    /**
+     * The synchronous body of `initializeUserCredits`.
+     *
+     * Kept `await`-free on purpose: `addCreditsV2` seeds a missing user *inside*
+     * its critical section, and an `await` between the payment-reference check
+     * and the transaction write opens a gap another caller can run through — two
+     * simultaneous first deliveries of the same reference would then both credit.
+     */
+    private seedUser;
     updateUserCredits(userId: string, updates: CreditBalanceUpdate): Promise<void>;
     updateUserTier(userId: string, input: TierUpdateInput): Promise<void>;
     createReservation(input: CreateReservationInput): Promise<PortableReservation>;
     getReservation(userId: string, reservationId: string): Promise<PortableReservation | null>;
     updateReservationStatus(userId: string, reservationId: string, status: ReservationStatus, completedAt?: Date): Promise<void>;
+    reserveCreditsV2(input: ReserveCreditsV2Input): Promise<ReserveOutcome>;
+    commitReservationV2(userId: string, reservationId: string, options?: ReservationTransitionOptions): Promise<CommitOutcome>;
+    releaseReservationV2(userId: string, reservationId: string, options?: ReservationTransitionOptions): Promise<ReleaseOutcome>;
+    expireReservationV2(userId: string, reservationId: string, options?: ExpireReservationV2Options): Promise<ExpireOutcome>;
     reserveCreditsAtomic(userId: string, amount: number, operationType: string, expiresAt: Date): Promise<PortableReservation>;
     commitReservationAtomic(userId: string, reservationId: string): Promise<void>;
     releaseReservationAtomic(userId: string, reservationId: string): Promise<void>;
+    /**
+     * The stored transaction carrying this reference, in *any* user's ledger.
+     *
+     * Deliberately not scoped to one user. The SQL adapter's unique index covers
+     * `payment_ref` alone, so searching only the crediting user's own history made
+     * the same reference credit two different accounts here while the SQL adapter
+     * treated the second delivery as a duplicate. See `core/payment-ref.ts`.
+     */
+    private findByPaymentRef;
+    /** The journal entry written alongside a stored purchase, if there is one. */
+    private journalForTransaction;
+    /**
+     * Credit an account, resolving `paymentRef` to created / replayed / conflict.
+     *
+     * The reference is checked and the transaction is recorded with no `await`
+     * between them. `createTransaction` is `async` but its body is synchronous, so
+     * under JavaScript's run-to-completion semantics no other caller can observe
+     * the gap — which is what stands in for the SQL adapter's unique index.
+     *
+     * A `replayed` or `conflict` outcome writes nothing at all: the check runs
+     * before the balance moves, not after.
+     */
+    addCreditsV2(input: AddCreditsV2Input): Promise<AddCreditsOutcome>;
+    /**
+     * The legacy signature, on top of {@link addCreditsV2}.
+     *
+     * `Promise<void>` has nowhere to report a conflict, and silently returning is
+     * indistinguishable from "credited" — the exact failure this round is closing
+     * — so a conflict throws. A genuine replay still returns quietly, because
+     * that *is* the idempotent no-op the caller asked for.
+     */
     addCreditsAtomic(userId: string, amount: number, description: string, paymentRef?: string, options?: AddCreditsAtomicOptions): Promise<void>;
     deductCreditsAtomic(userId: string, amount: number): Promise<{
         previousBalance: number;
         newBalance: number;
     }>;
     createTransaction(input: CreateTransactionInput): Promise<PortableTransaction>;
+    /** The unguarded writer, for `addCreditsV2` — which has moved the balance. */
+    private recordTransaction;
     getTransactions(userId: string, limit?: number, offset?: number): Promise<PortableTransaction[]>;
     logUsage(input: CreateUsageLogInput): Promise<PortableUsageLog>;
     getUsageLogs(query: UsageLogQuery): Promise<PortableUsageLog[]>;
     getUsageLogsCount(query: Omit<UsageLogQuery, "limit" | "offset">): Promise<number>;
     createJournalEntry(input: CreateJournalEntryInput): Promise<PortableJournalEntry>;
+    /**
+     * The synchronous body of `createJournalEntry`, so `atomicMonthlyReset` can
+     * write its journal line inside the same run-to-completion step as the
+     * balance write — an `await` between the two is exactly the gap that loses
+     * the line when the second half fails.
+     */
+    private recordJournalEntry;
     getJournalEntries(query: JournalEntryQuery): Promise<PortableJournalEntry[]>;
     getJournalEntriesCount(query: Omit<JournalEntryQuery, "limit" | "offset">): Promise<number>;
+    /**
+     * Expire every hold whose deadline has passed.
+     *
+     * Each candidate goes through the guarded {@link expireReservationV2}, which
+     * re-checks the status and the deadline under the user's lock. The previous
+     * implementation released the hold and then overwrote the status to
+     * `expired`, so a commit landing in between got its credits handed back and
+     * was then relabelled.
+     */
     findAndExpireReservations(_batchSize?: number, _maxIterations?: number): Promise<{
         expiredCount: number;
         creditsReleased: number;
@@ -82,6 +198,16 @@ declare class InMemoryCreditRepository implements ICreditRepository {
      * Clear all data (useful for testing)
      */
     clear(): void;
+    /**
+     * Install a yield point inside every V2 critical section (testing only).
+     *
+     * Unset, the critical sections run start-to-finish synchronously, so
+     * concurrent callers never interleave and a concurrency test would pass even
+     * with the locking removed. Setting this to a real yield (a macrotask or a
+     * barrier) makes callers genuinely overlap, so the tests exercise the lock
+     * instead of the event loop. Never call this in production code.
+     */
+    setSchedulingHook(hook: (() => Promise<void>) | undefined): void;
     /**
      * Get all users (useful for testing/debugging)
      */
@@ -97,4 +223,4 @@ declare class InMemoryCreditRepository implements ICreditRepository {
  */
 declare function createInMemoryCreditRepository(): InMemoryCreditRepository;
 
-export { AddCreditsAtomicOptions, CreateJournalEntryInput, CreateReservationInput, CreateTransactionInput, CreateUsageLogInput, CreditBalanceUpdate, ICreditRepository, InMemoryCreditRepository, JournalEntryQuery, TierUpdateInput, UsageLogQuery, createInMemoryCreditRepository, generateId, getNextMonthlyReset, toDate };
+export { AddCreditsAtomicOptions, AddCreditsV2Input, CreateJournalEntryInput, CreateReservationInput, CreateTransactionInput, CreateUsageLogInput, CreditBalanceUpdate, ExpireReservationV2Options, ICreditRepository, InMemoryCreditRepository, JournalEntryQuery, ReservationTransitionOptions, ReserveCreditsV2Input, TierUpdateInput, UsageLogQuery, addCreditsThroughRepository, commitThroughRepository, createInMemoryCreditRepository, generateId, getNextMonthlyReset, releaseThroughRepository, reserveThroughRepository, toDate };

package/dist/repository/index.d.ts

@@ -1,6 +1,60 @@
-import { I as ICreditRepository, d as CreditBalanceUpdate, T as TierUpdateInput, a as CreateReservationInput, A as AddCreditsAtomicOptions, b as CreateTransactionInput, c as CreateUsageLogInput, U as UsageLogQuery, C as CreateJournalEntryInput, J as JournalEntryQuery } from '../types-_bSybQnb.js';
-export { e as CreditRepositoryFactory, t as toClientUserCredits } from '../types-_bSybQnb.js';
-import { b as PortableUserCredits, S as SubscriptionTier, c as PortableReservation, R as ReservationStatus, P as PortableTransaction, d as PortableUsageLog, f as PortableJournalEntry, M as MonthlyResetResult, e as SubscriptionExpiryResult } from '../types-CjLj3GW5.js';
+import { I as ICreditRepository, b as AddCreditsV2Input, a as AddCreditsOutcome, l as ReservationTransitionOptions, C as CommitOutcome, R as ReleaseOutcome, m as ReserveCreditsV2Input, n as ReserveOutcome, g as CreditBalanceUpdate, o as TierUpdateInput, d as CreateReservationInput, i as ExpireReservationV2Options, E as ExpireOutcome, A as AddCreditsAtomicOptions, e as CreateTransactionInput, f as CreateUsageLogInput, U as UsageLogQuery, c as CreateJournalEntryInput, J as JournalEntryQuery } from '../types-BmG5Omzj.js';
+export { h as CreditRepositoryFactory, j as ICreditRepositoryCreditsV2, k as ICreditRepositoryV2, s as reservationJournalKey, t as supportsCreditsV2, u as supportsIdempotentCredit, v as toClientUserCredits } from '../types-BmG5Omzj.js';
+import { c as PortableUserCredits, S as SubscriptionTier, a as PortableReservation, R as ReservationStatus, P as PortableTransaction, d as PortableUsageLog, f as PortableJournalEntry, M as MonthlyResetResult, e as SubscriptionExpiryResult } from '../types-DJ8yqaVr.js';
+
+/**
+ * One reservation flow for both repository generations.
+ *
+ * Adapters that implement the V2 boundary get the idempotent, race-safe path
+ * and own their journal entry. Adapters that do not (Firestore, custom
+ * implementations) keep the legacy read-then-write path, with the service
+ * writing the journal exactly as it always did — so upgrading this package
+ * does not change their behaviour, and does not double-write anyone's ledger.
+ */
+
+/**
+ * Reserve credits through V2 when available.
+ *
+ * A legacy adapter cannot honour an idempotency key — it has no unique index
+ * to enforce it — so asking for one there is a caller error rather than a
+ * silently ignored option.
+ */
+declare function reserveThroughRepository(repository: ICreditRepository, input: ReserveCreditsV2Input): Promise<ReserveOutcome>;
+/**
+ * Commit through V2 when available, else the legacy read-then-write path.
+ *
+ * **The legacy path cannot promise a single winner.** It reads the status and
+ * then writes, with no lock and no compare-and-set between the two, so two
+ * concurrent commits of the same reservation can both observe `reserved` and
+ * both proceed. The typed outcome still describes what *this* call saw, but on
+ * a legacy adapter `committed` means "this call did the work", not "this call
+ * was the only one that did". Callers needing exactly-once must use a
+ * repository for which `supportsCreditsV2` returns `true`.
+ */
+declare function commitThroughRepository(repository: ICreditRepository, userId: string, reservationId: string, options?: ReservationTransitionOptions): Promise<CommitOutcome>;
+/**
+ * Release through V2 when available, else the legacy read-then-write path.
+ *
+ * Same caveat as {@link commitThroughRepository}: on a legacy adapter the
+ * read-then-write sequence is unguarded, so `released` does not exclude a
+ * concurrent commit having also run. Only V2 repositories serialise the two.
+ */
+declare function releaseThroughRepository(repository: ICreditRepository, userId: string, reservationId: string, options?: ReservationTransitionOptions): Promise<ReleaseOutcome>;
+/**
+ * Credit an account through the idempotent path when the adapter has one.
+ *
+ * A legacy adapter cannot resolve `created` / `replayed` / `conflict`: it has
+ * no global unique index over `payment_ref`, so it cannot tell a re-delivered
+ * webhook from a second, genuinely different payment that reuses a reference.
+ * Rather than invent an outcome, this reports `created` — which is what the
+ * legacy method actually did — and the ambiguity is documented on the return
+ * type instead of hidden inside it.
+ *
+ * The reference is normalised here as well as in the adapters, so a legacy
+ * adapter that stores the raw string does not persist a whitespace-only
+ * reference that would then deduplicate nothing.
+ */
+declare function addCreditsThroughRepository(repository: ICreditRepository, input: AddCreditsV2Input): Promise<AddCreditsOutcome>;
 
 /**
  * Shared utilities for credit repository implementations
@@ -36,41 +90,103 @@ declare function getNextMonthlyReset(from?: Date): Date;
  * - Reference implementation for custom repositories
  */
 
-/**
- * In-Memory implementation of ICreditRepository
- *
- * Implements all repository methods using Map-based storage.
- * Useful for testing and as a reference implementation.
- */
 declare class InMemoryCreditRepository implements ICreditRepository {
-    private users;
-    private reservations;
-    private transactions;
-    private usageLogs;
-    private journalEntries;
+    private readonly store;
+    /**
+     * A copy, never the live record.
+     *
+     * Handing out the stored object made this adapter behave unlike any real
+     * one: a caller holding a "before" snapshot saw it mutate under them. The
+     * service's monthly reset compared `resetResult.credits.balance` against the
+     * balance it had read moments earlier, got zero because both were the same
+     * object, and silently skipped the reset's journal entry — while the SQL
+     * adapter, which maps each row into a fresh object, wrote it.
+     */
     getUserCredits(userId: string): Promise<PortableUserCredits | null>;
     initializeUserCredits(userId: string, tier: SubscriptionTier, initialBalance: number): Promise<PortableUserCredits>;
+    /**
+     * The synchronous body of `initializeUserCredits`.
+     *
+     * Kept `await`-free on purpose: `addCreditsV2` seeds a missing user *inside*
+     * its critical section, and an `await` between the payment-reference check
+     * and the transaction write opens a gap another caller can run through — two
+     * simultaneous first deliveries of the same reference would then both credit.
+     */
+    private seedUser;
     updateUserCredits(userId: string, updates: CreditBalanceUpdate): Promise<void>;
     updateUserTier(userId: string, input: TierUpdateInput): Promise<void>;
     createReservation(input: CreateReservationInput): Promise<PortableReservation>;
     getReservation(userId: string, reservationId: string): Promise<PortableReservation | null>;
     updateReservationStatus(userId: string, reservationId: string, status: ReservationStatus, completedAt?: Date): Promise<void>;
+    reserveCreditsV2(input: ReserveCreditsV2Input): Promise<ReserveOutcome>;
+    commitReservationV2(userId: string, reservationId: string, options?: ReservationTransitionOptions): Promise<CommitOutcome>;
+    releaseReservationV2(userId: string, reservationId: string, options?: ReservationTransitionOptions): Promise<ReleaseOutcome>;
+    expireReservationV2(userId: string, reservationId: string, options?: ExpireReservationV2Options): Promise<ExpireOutcome>;
     reserveCreditsAtomic(userId: string, amount: number, operationType: string, expiresAt: Date): Promise<PortableReservation>;
     commitReservationAtomic(userId: string, reservationId: string): Promise<void>;
     releaseReservationAtomic(userId: string, reservationId: string): Promise<void>;
+    /**
+     * The stored transaction carrying this reference, in *any* user's ledger.
+     *
+     * Deliberately not scoped to one user. The SQL adapter's unique index covers
+     * `payment_ref` alone, so searching only the crediting user's own history made
+     * the same reference credit two different accounts here while the SQL adapter
+     * treated the second delivery as a duplicate. See `core/payment-ref.ts`.
+     */
+    private findByPaymentRef;
+    /** The journal entry written alongside a stored purchase, if there is one. */
+    private journalForTransaction;
+    /**
+     * Credit an account, resolving `paymentRef` to created / replayed / conflict.
+     *
+     * The reference is checked and the transaction is recorded with no `await`
+     * between them. `createTransaction` is `async` but its body is synchronous, so
+     * under JavaScript's run-to-completion semantics no other caller can observe
+     * the gap — which is what stands in for the SQL adapter's unique index.
+     *
+     * A `replayed` or `conflict` outcome writes nothing at all: the check runs
+     * before the balance moves, not after.
+     */
+    addCreditsV2(input: AddCreditsV2Input): Promise<AddCreditsOutcome>;
+    /**
+     * The legacy signature, on top of {@link addCreditsV2}.
+     *
+     * `Promise<void>` has nowhere to report a conflict, and silently returning is
+     * indistinguishable from "credited" — the exact failure this round is closing
+     * — so a conflict throws. A genuine replay still returns quietly, because
+     * that *is* the idempotent no-op the caller asked for.
+     */
     addCreditsAtomic(userId: string, amount: number, description: string, paymentRef?: string, options?: AddCreditsAtomicOptions): Promise<void>;
     deductCreditsAtomic(userId: string, amount: number): Promise<{
         previousBalance: number;
         newBalance: number;
     }>;
     createTransaction(input: CreateTransactionInput): Promise<PortableTransaction>;
+    /** The unguarded writer, for `addCreditsV2` — which has moved the balance. */
+    private recordTransaction;
     getTransactions(userId: string, limit?: number, offset?: number): Promise<PortableTransaction[]>;
     logUsage(input: CreateUsageLogInput): Promise<PortableUsageLog>;
     getUsageLogs(query: UsageLogQuery): Promise<PortableUsageLog[]>;
     getUsageLogsCount(query: Omit<UsageLogQuery, "limit" | "offset">): Promise<number>;
     createJournalEntry(input: CreateJournalEntryInput): Promise<PortableJournalEntry>;
+    /**
+     * The synchronous body of `createJournalEntry`, so `atomicMonthlyReset` can
+     * write its journal line inside the same run-to-completion step as the
+     * balance write — an `await` between the two is exactly the gap that loses
+     * the line when the second half fails.
+     */
+    private recordJournalEntry;
     getJournalEntries(query: JournalEntryQuery): Promise<PortableJournalEntry[]>;
     getJournalEntriesCount(query: Omit<JournalEntryQuery, "limit" | "offset">): Promise<number>;
+    /**
+     * Expire every hold whose deadline has passed.
+     *
+     * Each candidate goes through the guarded {@link expireReservationV2}, which
+     * re-checks the status and the deadline under the user's lock. The previous
+     * implementation released the hold and then overwrote the status to
+     * `expired`, so a commit landing in between got its credits handed back and
+     * was then relabelled.
+     */
     findAndExpireReservations(_batchSize?: number, _maxIterations?: number): Promise<{
         expiredCount: number;
         creditsReleased: number;
@@ -82,6 +198,16 @@ declare class InMemoryCreditRepository implements ICreditRepository {
      * Clear all data (useful for testing)
      */
     clear(): void;
+    /**
+     * Install a yield point inside every V2 critical section (testing only).
+     *
+     * Unset, the critical sections run start-to-finish synchronously, so
+     * concurrent callers never interleave and a concurrency test would pass even
+     * with the locking removed. Setting this to a real yield (a macrotask or a
+     * barrier) makes callers genuinely overlap, so the tests exercise the lock
+     * instead of the event loop. Never call this in production code.
+     */
+    setSchedulingHook(hook: (() => Promise<void>) | undefined): void;
     /**
      * Get all users (useful for testing/debugging)
      */
@@ -97,4 +223,4 @@ declare class InMemoryCreditRepository implements ICreditRepository {
  */
 declare function createInMemoryCreditRepository(): InMemoryCreditRepository;
 
-export { AddCreditsAtomicOptions, CreateJournalEntryInput, CreateReservationInput, CreateTransactionInput, CreateUsageLogInput, CreditBalanceUpdate, ICreditRepository, InMemoryCreditRepository, JournalEntryQuery, TierUpdateInput, UsageLogQuery, createInMemoryCreditRepository, generateId, getNextMonthlyReset, toDate };
+export { AddCreditsAtomicOptions, AddCreditsV2Input, CreateJournalEntryInput, CreateReservationInput, CreateTransactionInput, CreateUsageLogInput, CreditBalanceUpdate, ExpireReservationV2Options, ICreditRepository, InMemoryCreditRepository, JournalEntryQuery, ReservationTransitionOptions, ReserveCreditsV2Input, TierUpdateInput, UsageLogQuery, addCreditsThroughRepository, commitThroughRepository, createInMemoryCreditRepository, generateId, getNextMonthlyReset, releaseThroughRepository, reserveThroughRepository, toDate };