@phala/pay-server 0.13.3 → 0.13.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -103,6 +103,8 @@ Retries cover network/timeouts, 429, 500/502/503/504, and only `409 idempotency_
103
103
  bounded exponential jitter and Retry-After as a minimum. A delay that exceeds the remaining budget
104
104
  returns the last error immediately. Replayed errors, DELETE, cancellation and redirects do not
105
105
  retry. Redirects are refused. `close()` aborts outstanding requests without closing injected fetch.
106
+ An unsaved `503 unavailable` from authentication admission uses this same retry policy and
107
+ retains the original POST body and idempotency key.
106
108
 
107
109
  Set `upgradeTolerance: true` on the client or per call for backend work that can wait through a
108
110
  CVM upgrade. A maintenance 503, gateway 502/503/504 (even a non-JSON body), or network/attempt
@@ -631,10 +631,21 @@ export interface paths {
631
631
  * `deposit.refunded` is sent; otherwise it is `failed` with a `failure_reason`. Repeating the same
632
632
  * transaction returns the refund. From here on the refund cannot be canceled: it is `failed`
633
633
  * only when its transaction is proven not to pay it.
634
- * Each environment has a configured attached-pending refund limit (production 2, staging 1),
635
- * and permits one new attachment per
636
- * rolling 24 hours across all accounts and modes. Repeating the same attachment consumes no
637
- * quota. A limit refusal preserves the reservation; contact the operator before another payout.
634
+ * Environment-wide attached-pending and rolling 24-hour limits apply across accounts and modes.
635
+ * An additional per-account concurrency cap (`max_attached_pending_refunds_per_account`,
636
+ * default 1) also spans both modes. Repeating an
637
+ * attachment consumes no quota. A refusal preserves the reservation; contact the operator.
638
+ * To resolve a replaced attachment, repeat its original `transaction_hash` with optional
639
+ * `replacement_transaction_hash`. One candidate is stored at a time, with at most eight recovery
640
+ * passes on the same A/C backoff. Before exhaustion or 24 hours, identical re-POSTs are
641
+ * idempotent no-ops. After both, an explicit re-POST renews that candidate (or supplies another)
642
+ * at most once per 24 hours per attachment; never automatically. Only identical
643
+ * finalized replacement receipts on both providers and the original's verified sender and
644
+ * nonce prove `transaction_dropped`; missing receipts and account nonce changes never suffice.
645
+ * If providers have forgotten the original, supply `original_signed_transaction` alongside
646
+ * the candidate. Its hash must equal `transaction_hash`; local signature recovery supplies the
647
+ * original sender/nonce only when they were not already captured from both providers. Raw
648
+ * bytes are not stored and this fallback makes no RPC calls.
638
649
  */
639
650
  readonly post: operations["mark_refund_paid"];
640
651
  readonly delete?: never;
@@ -2756,6 +2767,14 @@ export interface components {
2756
2767
  * }
2757
2768
  */
2758
2769
  readonly MarkRefundPaidRequest: {
2770
+ /**
2771
+ * @description Optional 0x-prefixed EIP-2718 signed original transaction, with a replacement candidate.
2772
+ * Its keccak256 must equal transaction_hash and its signature must recover a sender. When
2773
+ * the original's sender/nonce were not captured from both providers before eviction, these
2774
+ * locally verified fields allow replacement proof with no additional RPC. Raw bytes are not
2775
+ * stored. Legacy, EIP-2930, EIP-1559, EIP-4844 and EIP-7702 envelopes are supported.
2776
+ */
2777
+ readonly original_signed_transaction?: string | null;
2759
2778
  /**
2760
2779
  * Format: int64
2761
2780
  * @description Position of the `Transfer` log that pays the refund among the logs of the transaction's
@@ -2763,6 +2782,15 @@ export interface components {
2763
2782
  * is re-included in another block; any matching log when absent.
2764
2783
  */
2765
2784
  readonly receipt_log_index?: number | null;
2785
+ /**
2786
+ * @description Optional replacement candidate for the original transaction_hash. The original remains
2787
+ * reserved until both providers finalize this distinct transaction and prove the same
2788
+ * sender and nonce as the original. Nonce changes or missing receipts alone prove nothing.
2789
+ * At most eight automatic recovery passes per epoch. Before exhaustion or 24 hours,
2790
+ * identical re-POSTs are idempotent no-ops. After both, an explicit re-POST renews the same
2791
+ * candidate (or supplies another), at most once per 24 hours per attachment; never automatic.
2792
+ */
2793
+ readonly replacement_transaction_hash?: string | null;
2766
2794
  /** @description Hash of the transaction that pays the refund from the treasury of the deposit's address. */
2767
2795
  readonly transaction_hash: string;
2768
2796
  };
@@ -3379,8 +3407,9 @@ export interface components {
3379
3407
  /**
3380
3408
  * @description Why the refund failed: `transaction_failed`, `transfer_not_found`, `sender_mismatch`,
3381
3409
  * `destination_mismatch`, `amount_mismatch`, or `transfer_already_used`.
3382
- * Historical refunds may retain `transaction_dropped` or `transaction_not_found`; missing
3383
- * transactions now remain pending with their reservation and alert after 24 hours.
3410
+ * `transaction_dropped` requires a distinct replacement finalized on both providers with
3411
+ * the original transaction's dual-verified sender and nonce. Historical refunds may retain
3412
+ * `transaction_not_found`; missing transactions remain pending and alert after 24 hours.
3384
3413
  * New values may be added.
3385
3414
  */
3386
3415
  readonly failure_reason?: string | null;