MemoryLockContractError — @gj-kit/toss-payments-postgresql

@gj-kit/toss-payments-postgresql/testing에서 공개하는 class입니다. package version 0.5.1의 release declaration을 그대로 표시합니다.

검증된 import 예제

import { MemoryLockContractError } from '@gj-kit/toss-payments-postgresql/testing';

시그니처, 매개변수, 반환 타입

/**
 * Thrown by the in-memory aggregate where the PostgreSQL aggregate would deadlock or lose its
 * single-transaction guarantee. `code` is the contract; messages carry no keys or secrets.
 *
 * Nesting is detected through `AsyncLocalStorage`, so it is judged by where a lock API call is
 * *started*, not by whether the callback awaits it: a lock call launched inside a callback and
 * left un-awaited (for example a "late webhook" fired while the issuance callback still holds
 * the lock) is refused exactly like an awaited one, even though PostgreSQL with a pool larger
 * than one would queue it and serve it after the commit. This is the fake's deliberate stricter
 * direction — it cannot tell the two apart and the awaited form is a real self-deadlock. To model
 * a competing caller, start it from outside the callback after a "started" gate, as in the README
 * contention example. Work scheduled from a callback that runs *after* the callback settled
 * (timers, `setImmediate`) is not nesting and is served normally.
 */
declare class MemoryLockContractError extends Error {
    readonly name = "MemoryLockContractError";
    readonly code: MemoryLockContractErrorCode;
    constructor(code: MemoryLockContractErrorCode, message: string);
}

이 선언은 매개변수, optionality, 제네릭, 반환값, 공개 union/type 계약의 정본입니다. 호출 전 필요한 환경·권한·오류 경계는 패키지 Golden path와 이 subpath의 import 조건을 함께 확인하세요.

Release context

• 패키지: @gj-kit/toss-payments-postgresql
• 버전: 0.5.1
• 공개 entry: ./testing
• 소스: GitHub

구현 주석

Thrown by the in-memory aggregate where the PostgreSQL aggregate would deadlock or lose its single-transaction guarantee. code is the contract; messages carry no keys or secrets.

Nesting is detected through AsyncLocalStorage, so it is judged by where a lock API call is started, not by whether the callback awaits it: a lock call launched inside a callback and left un-awaited (for example a “late webhook” fired while the issuance callback still holds the lock) is refused exactly like an awaited one, even though PostgreSQL with a pool larger than one would queue it and serve it after the commit. This is the fake’s deliberate stricter direction — it cannot tell the two apart and the awaited form is a real self-deadlock. To model a competing caller, start it from outside the callback after a “started” gate, as in the README contention example. Work scheduled from a callback that runs after the callback settled (timers, setImmediate) is not nesting and is served normally.