Gift-wrap redelivery on restart re-sends "Order already received" to every past customer and inflates unread counts #11
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The kind-1059 subscription deliberately has no
since(nostr/nostr_client.py:152-161, correct per NIP-59), so every (re)subscribe redelivers all stored wraps for the merchant. Dedup is a 1000-entry in-memory set that starts empty on each process start (nostr_client.py:73-80)._handle_incoming_dms(services.py:656-682) then runs non-idempotent side effects regardless:increment_customer_unread_messagesat:663, and after_persist_dmsilently returns the already-stored row (crud.py:768ON CONFLICT(event_id) DO NOTHING+:781-786lookup by event_id) it still enters_handle_incoming_structured_dm→_handle_new_order, whose duplicate-order branch (services.py:803-814) returns a payment-request DM saying "Order already received and processed" thatreply_to_structured_dm(:680) publishes to the customer. A merchant with N processed orders spams N customers on every deploy/restart; the 120 s stale-subscription monitor adds more redeliveries. Alsois_duplicate_eventmarks the id seen before processing (services.py:518), so a transient bunker failure duringunwrap_messageloses the event for the cache lifetime.Fix direction: check
get_direct_message_by_event_idbefore incrementing unread / dispatching structured handling and return early if the row already exists; mark events seen only after successful processing; consider persisting seen ids so restarts don't depend on relay behavior.Found during reforge run #1 (sandbox nostrmarket#13).