#51 - NIP-52 publish can be skipped silently — both early-returns need to log - aiolabs/events

padreug commented

2026-09-26 12:42:34 +00:00

Owner

publish_or_delete_nostr_event has two paths that skip publishing without leaving anything in the journal at INFO:

nostr_hooks.py:34 — if signer is None: return. Bare return, no log at any level.
nostr_publisher.py:175 — if not nostr_client: logger.debug(...). LNbits runs at INFO, so it never appears.

On cfaun this hid a 14-day inventory drift on Q6mhQQzQPSXqkQuFndzXnf (URU ECSTATIC DANCE). The event sold 5 tickets; the relay kept serving tickets_available=48 tickets_sold=2 from Sep 12, and oyez.ariege.io rendered 48 because that's what the relay gave it.

Timeline from the ticket table and the journal:

Sep 12 11:05:40  tickets 1+2 paid
Sep 12 11:07:47  Published NIP-52 calendar event: 81709fa3... / 756fed21...   <- last success
Sep 20 13:00:50  lnbits restart, NostrClient connected 13:01:00, subscribed 13:01:05
Sep 21 13:39:01  tickets 3+4 paid   -> no log at all
Sep 23 14:19:58  ticket 5 paid      -> no log at all

sold reached 5 in the DB, and only set_ticket_paid writes that counter, so the publish hook definitely ran three more times. events.nostr_event_created_at is still 1789211268 and nostr_event_id still 756fed21…, which is what the relay holds — so no publish succeeded after Sep 12.

The absence of a log line is itself the proof of where it bailed: publish_event_to_nostr logs Published NIP-52 calendar event immediately after await nostr_client.publish_nostr_event(...), and that call only puts the event on send_req_queue — it confirms nothing. So the success line fires even when the relay never receives the event. Not seeing it means we never reached it, i.e. one of the two silent returns above.

What to change

Both skips should log at WARNING with the event id, e.g.

logger.warning(f"[EVENTS] No signer for wallet {event.wallet}, skipping NIP-52 publish for {event.id}")
logger.warning(f"[EVENTS] No NostrClient, skipping NIP-52 publish for {event.id}")

A skipped publish means the public ticket count silently stops tracking reality — that is not a debug-level event.

Side note for whoever picks this up

Until this lands, the two branches are distinguishable by running the instance at DEBUG and re-triggering a publish (edit the event in the admin UI):

[EVENTS] No NostrClient available, skipping publish appears → the nostr_client global is falsy
nothing appears at all → resolve_for_wallet(event.wallet) returned None

On cfaun the Sep 20 start was clean and single (one Registered nostr-transport RPCs, NostrClient connected and subscribed), which makes the signer branch the better bet there — worth confirming before assuming.

`publish_or_delete_nostr_event` has two paths that skip publishing without leaving anything in the journal at INFO: - `nostr_hooks.py:34` — `if signer is None: return`. Bare return, no log at any level. - `nostr_publisher.py:175` — `if not nostr_client: logger.debug(...)`. LNbits runs at INFO, so it never appears. On cfaun this hid a 14-day inventory drift on `Q6mhQQzQPSXqkQuFndzXnf` (URU ECSTATIC DANCE). The event sold 5 tickets; the relay kept serving `tickets_available=48 tickets_sold=2` from Sep 12, and oyez.ariege.io rendered 48 because that's what the relay gave it. Timeline from the ticket table and the journal: ``` Sep 12 11:05:40 tickets 1+2 paid Sep 12 11:07:47 Published NIP-52 calendar event: 81709fa3... / 756fed21... <- last success Sep 20 13:00:50 lnbits restart, NostrClient connected 13:01:00, subscribed 13:01:05 Sep 21 13:39:01 tickets 3+4 paid -> no log at all Sep 23 14:19:58 ticket 5 paid -> no log at all ``` `sold` reached 5 in the DB, and only `set_ticket_paid` writes that counter, so the publish hook definitely ran three more times. `events.nostr_event_created_at` is still 1789211268 and `nostr_event_id` still `756fed21…`, which is what the relay holds — so no publish succeeded after Sep 12. The absence of a log line is itself the proof of where it bailed: `publish_event_to_nostr` logs `Published NIP-52 calendar event` immediately after `await nostr_client.publish_nostr_event(...)`, and that call only puts the event on `send_req_queue` — it confirms nothing. So the success line fires even when the relay never receives the event. Not seeing it means we never reached it, i.e. one of the two silent returns above. ## What to change Both skips should log at WARNING with the event id, e.g. - `logger.warning(f"[EVENTS] No signer for wallet {event.wallet}, skipping NIP-52 publish for {event.id}")` - `logger.warning(f"[EVENTS] No NostrClient, skipping NIP-52 publish for {event.id}")` A skipped publish means the public ticket count silently stops tracking reality — that is not a debug-level event. ## Side note for whoever picks this up Until this lands, the two branches are distinguishable by running the instance at DEBUG and re-triggering a publish (edit the event in the admin UI): - `[EVENTS] No NostrClient available, skipping publish` appears → the `nostr_client` global is falsy - nothing appears at all → `resolve_for_wallet(event.wallet)` returned None On cfaun the Sep 20 start was clean and single (one `Registered nostr-transport RPCs`, NostrClient connected and subscribed), which makes the signer branch the better bet there — worth confirming before assuming.

padreug referenced this issue

2026-09-26 12:42:47 +00:00

A lost NIP-52 republish is permanent — nothing reconciles the relay copy #52

padreug referenced this issue

2026-09-26 21:31:44 +00:00

Nostr publish failures are silently swallowed — inventory counters drift with no retry and no operator signal #35

padreug referenced this issue

2026-09-26 21:32:19 +00:00

A lost NIP-52 republish is permanent — nothing reconciles the relay copy #52

padreug referenced this issue

2026-09-26 21:32:43 +00:00

Rebase fork onto upstream v1.6.8 (waves / on-chain / approval reconciliation) #33