PgWebhookDedupeStoreOptions — @gj-kit/toss-payments-postgresql
A public interface from @gj-kit/toss-payments-postgresql. The signature below is taken directly from the 0.5.1 release declaration.
Verified import example
Section titled “Verified import example”import { PgWebhookDedupeStoreOptions } from '@gj-kit/toss-payments-postgresql';Signature, parameters, and return type
Section titled “Signature, parameters, and return type”/** * WebhookDedupeStore PostgreSQL 구현 (설계 §3.5). * * 코어 계약의 핵심 불변식(verifier.ts TSDoc): * - **claim은 원자적이어야 한다** — 조회 후 생성하는 2단계 구현은 TOCTOU 레이스라 * 금지. 그래서 INSERT ... ON CONFLICT DO UPDATE + CTE **단일 문**으로 전이한다. * - processing 레코드는 lease 만료 후 재점유 가능해야 한다(crash-recovery). * - completed에는 토스의 최장 재전송 기간보다 긴 TTL(권장 5일)을 적용한다 — * TTL 삭제는 cleanup()(팩토리) 소관이며 이 스토어는 지우지 않는다. * - `complete`는 비즈니스 핸들러의 내구적 처리 완료 후에만, `release`는 처리 실패 시 * 재전송 재점유를 위해 호출된다 — release는 completed 행을 절대 지우지 않는다. * - ⚠ 알려진 계약 한계: 코어 `release(dedupeKey)`에는 소유 토큰(fencing token)이 * 없다 — lease 만료 후 다른 워커가 재점유한 뒤에 도착한 원래 워커의 늦은 release가 * 새 claim의 processing 행을 지울 수 있는 창이 이론상 존재한다(이후 재전송이 * 'claimed'를 받아 동시 처리 창이 열림). 스토어 구현만으로는 어느 워커의 release인지 * 판별할 수 없어 이 계층에서 완전 차단이 불가능하다(코어 계약 보완 후보). 실전 * 완화책은 `dedupe.leaseSeconds`(기본 60)를 핸들러 최대 처리 시간보다 길게 잡는 것. */interface PgWebhookDedupeStoreOptions extends PgStoreOptions { /** processing 행의 crash-recovery lease(초). 기본 60. */ readonly leaseSeconds?: number;}This declaration is the source of truth for parameters, optionality, generics, return values, and public union/type contracts. Check the package golden path and this subpath’s import conditions for required environment, permission, and error boundaries before calling it.
Release context
Section titled “Release context”- Package:
@gj-kit/toss-payments-postgresql - Version:
0.5.1 - Public entry:
. - Source: GitHub