A lost NIP-52 republish is permanent — nothing reconciles the relay copy #52
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?
Ticket inventory reaches clients only through the NIP-52 republish in
set_ticket_paid. That republish is fire-and-forget, and if it's lost the relay keeps serving the stale count forever — nothing retries, and nothing ever compares what the relay holds against the DB.That's what happened on cfaun (see #51 for the diagnosis): the relay served
tickets_available=48for 14 days while the DB said 45, and the only reason it got noticed was someone reading the public page.Every layer drops the event quietly:
NostrClient.publish_nostr_eventjust doesawait self.send_req_queue.put(["EVENT", e.dict()])— no OK, no confirmation.run_forever(nostr/nostr_client.py:78-89) dequeues, thenself.ws.send(...). If that raises, the event is already off the queue and is never retried; the loop logs a warning and sleeps 60s.is_websocket_connectedreturnsself.ws.keep_running, which stays True on a half-dead socket, so sends can also vanish with no exception at all.publish_event_to_nostrlogsPublished NIP-52 calendar eventright after the queue put, so that line means "queued", not "the relay has it".What would fix it
Roughly in order of value:
event.sold/event.amount_ticketsand republishes when it doesn't. This is the piece that turns a lost publish from permanent drift into a blip, and it covers every cause including ones we haven't thought of.run_forever, on a send failure put the request back (or hold it) rather than dropping it on the floor.publish_nostr_eventcould await the OK frame and surface a rejection, so "Published" means published.(1) alone would have kept oyez correct through this incident even with everything else unchanged.
Duplicate of #35, which covers the same drift with more evidence (the 2026-09-05 aio-demo incident) and a fuller proposal. Filed this before checking the tracker — my mistake.
The one thing here that wasn't in #35 — the cfaun occurrence and the fact that it came in through a silent path rather than a swallowed exception — is now recorded as a comment on #35. The logging half is #51.
Closing.