01a051eb - Persist forum invoice attempts and zap ingest decisions - #68
Merged
Conversation
POST /messages/:id/invoice now writes every attempt (success and failure) to message_invoice, including the BOLT11, description vs description_hash, and whether the invoice is a NIP-57 hash invoice. kind:9735 ingest records indexed and rejected outcomes in nostr_zap_ingest. Operators can list both via DEBUG_TOKEN GET /debug/invoices and GET /debug/zap-ingests.
Handbook bullets for migrateMessageSchema and InMemoryMessageStore now name message_invoice, nostr_zap_ingest, and the matching store methods.
CI lint failed prettier --check on three files; this matches the repo style.
Adds tests for null/array JSON mapping, sign_failed invoice rows, a non-object signed zap request, and ingest errors without a string pubkey so coverage meets the 100% gate.
Adds GET /debug/invoices and GET /debug/zap-ingests to the route table and contracts, and names the new tables in the CONTRIBUTING schema tree.
POST /messages/:id/invoice now uses the same uuid check as photo fetch, so Postgres is not asked to cast garbage into message_invoice.message_id.
Invoice tests with a non-integer sats body now use a uuid path so the new invoice id check does not turn them into 404.
POST /messages/:id/invoice now states the UUID guard, best-effort message_invoice rows, and the full result union on GET /debug/invoices.
GitHub did not start check-runs on the previous two commits.
TaprootFreakAI
force-pushed
the
01a051eb-persist-forum-invoices
branch
from
August 30, 2026 12:53
eab875c to
d09c919
Compare
After the NIP-65 rebase, MessageStore includes listSignedMissingPhoto and resetSignedEvent; the invoice/ingest test doubles now implement them.
Ignores zod/cap and missing-key persist that sit behind existing v8 guards, records a null zap_request bind, and marks the catch-path pubkey ternary as unreachable after the ingest guard.
The ok persist path records paymentHash and descriptionHash when the BOLT11 inspects, covering the non-null optional-chaining branches.
Collaborator
Author
|
EN: DE: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
EN:
Forum payment attempts and kind:9735 ingest decisions are stored in Postgres so operators can debug zap invoices without screenshots. Each invoice row keeps the BOLT11, description versus description_hash, and whether it is a NIP-57 hash invoice. Rejected zap receipts are stored with a reason, not only logged. Debug listing is behind DEBUG_TOKEN.
DE:
Forum-Zahlungsversuche und kind:9735-Ingest-Entscheidungen liegen in Postgres, damit sich Zap-Invoices ohne Screenshots debuggen lassen. Jede Invoice-Zeile hält Bolt11, description gegen description_hash und ob es eine NIP-57-Hash-Invoice ist. Abgelehnte Zap-Receipts werden mit Grund gespeichert, nicht nur geloggt. Die Debug-Liste hängt an DEBUG_TOKEN.
Details
Problem:
POST /messages/:id/invoicereturned a BOLT11 and discarded it. A Wallet of Satoshi fallback invoice (plaintext 9734 JSON indescriptioninstead ofdescription_hash) could be paid without ever creating a zap receipt, and the database had no copy of the invoice.This change:
message_invoice(every attempt after auth: ok, noZap, unreachable, no_event, and other results).nostr_zap_ingest(indexed or rejected, with reason).inspectBolt11/isNip57Invoicewithout changingdecodeBolt11.GET /debug/invoicesandGET /debug/zap-ingests(DEBUG_TOKEN).No nsec is stored.