NotificationAccountLifecycle — @gj-kit/nest-notifications

@gj-kit/nest-notifications/core에서 공개하는 interface입니다. package version 0.1.1의 release declaration을 그대로 표시합니다.

검증된 import 예제

import { NotificationAccountLifecycle } from '@gj-kit/nest-notifications/core';

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

/**
 * Host bridge for account deletion. Call both methods inside the same host
 * transaction as the deletion itself; the ordering obligations L1-L4 are the
 * entire basis of G7 ("no delivery after a tombstone"), and nothing in this
 * library can enforce them.
 *
 * - **L1** — `tombstone` and every delete run in one transaction with the
 *   account deletion. Commit the tombstone first and a relay running in between
 *   leaves a delivery behind; commit the purge first and a late stage creates a
 *   new outbox row.
 * - **L2** — delete ingress rows *before* deliveries: the ingress `DELETE` blocks
 *   on the relay transaction's row lock (R7), so that relay serialises either
 *   side of this statement, and the delivery/message deletes that follow remove
 *   whatever it just committed. Delete deliveries first and a relay that
 *   committed in between survives the deletion and pushes.
 * - **L3** — the tombstone row survives; everything else goes.
 * - **L4** — `anonymizeActor` clears actor references left in *other* recipients'
 *   messages. A recipient purge does not do it for you.
 *
 * The full order is: tombstone -> ingress -> delivery -> message -> endpoint ->
 * preference.
 */
interface NotificationAccountLifecycle<Transaction = unknown> {
    purgeRecipient(transaction: Transaction, applicationKey: string, recipientRef: string): Promise<void>;
    anonymizeActor(transaction: Transaction, applicationKey: string, actorRef: string): Promise<void>;
}

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

Release context

• 패키지: @gj-kit/nest-notifications
• 버전: 0.1.1
• 공개 entry: ./core
• 소스: GitHub

구현 주석

Host bridge for account deletion. Call both methods inside the same host transaction as the deletion itself; the ordering obligations L1-L4 are the entire basis of G7 (“no delivery after a tombstone”), and nothing in this library can enforce them.

• L1 — tombstone and every delete run in one transaction with the account deletion. Commit the tombstone first and a relay running in between leaves a delivery behind; commit the purge first and a late stage creates a new outbox row.
• L2 — delete ingress rows before deliveries: the ingress DELETE blocks on the relay transaction’s row lock (R7), so that relay serialises either side of this statement, and the delivery/message deletes that follow remove whatever it just committed. Delete deliveries first and a relay that committed in between survives the deletion and pushes.
• L3 — the tombstone row survives; everything else goes.
• L4 — anonymizeActor clears actor references left in other recipients’ messages. A recipient purge does not do it for you.

The full order is: tombstone -> ingress -> delivery -> message -> endpoint -> preference.