feat(payments): subscription lifecycle, renewal invoices and plan-based write access
Maintainer thường phản hồi trong vòng 1 ngày
@Priyanshubhartistm đang làm issue này rồi.
Từ ngày 19/10/2026.
- #909 của @Priyanshubhartistm — đang mở
Đánh giá
Issue này chưa được đánh giá.
Mô tả
Is your feature request related to a problem? Please describe.
With the subscription data model in place, nothing creates or extends a subscription, issues renewal invoices, or ends access when a period lapses. Write access still depends only on the permanent is_admitted flag.
Describe the solution you'd like
- A
SubscriptionServicefor subscribe, renew and status transitions (active → renewal_pending → past_due → expired). PaymentsService.confirmInvoiceextends the subscription period (same transaction as the invoice confirmation). All five confirmation paths (maintenance poll and the Zebedee/LNbits/OpenNode/Nodeless callbacks) already go through it, so the invoice carries itsplan_idinstead of each callback learning about plans.POST /invoicesaccepts a plan id; existing admission behaviour is unchanged when no plans are configured.- A periodic sweep (maintenance worker) that issues renewal invoices before period end and moves overdue subscriptions through grace to expired.
isUserAdmittedchecks for an active subscription, reusing the existing admission cache so there is no extra database read per event.- Tests for each transition, the confirm path, and the cache behaviour.
Additional context
- Design: #673. Renewal is invoice-based: Lightning cannot pull funds, so the relay issues a renewal invoice and the user pays it.
- Ngôn ngữ chính
- TypeScript
- Star
- 829
- Fork
- 234
- Merge trung bình
- 17 giờ 46 phút
- Pull request đã merge (30 ngày)
- 73
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của cameri/nostream
-
Website
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Three repositories have no unit tests (notification-outbox, notification-delivery-log, nip05-verification)Có thể đã có người làm @Priyanshubhartistm đã nhận 1 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 72/100
cameri/nostream#905 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
No unit tests for four of six payment processors (nodeless, lnurl, opennode, zebedee)Có thể đã có người làm @Priyanshubhartistm đã nhận 1 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 72/100
cameri/nostream#903 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
cameri/nostream#902 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của cameri/nostream
Issue tương tự
-
ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
xavxyz/bei-shan-lin-shui#57 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] rag: sentence content can cross the reported sentence boundariesCó thể đã có người làm @LJK-ikun đã nhận hôm nay. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
README: the Resource URI Schemas example's file://documents/* pattern only matches that literal URIĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
platformatic/mcp#361 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
最近文档这个弹窗，左右宽度没有最小宽度限制Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
siyuan-note/siyuan#20799 · 7 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày