feat(nostr): publish the active ticket wave, not the roll-up
Some checks failed
lint.yml / feat(nostr): publish the active ticket wave, not the roll-up (pull_request) Failing after 0s
Some checks failed
lint.yml / feat(nostr): publish the active ticket wave, not the roll-up (pull_request) Failing after 0s
Since upstream v1.6.8 price, currency and inventory belong to time-boxed ticket waves, and the event-level fields `sync_event_ticket_waves` derives are the PRIMARY wave's price/currency and the SUM of every wave's stock. The NIP-52 publisher read those, so as soon as an organiser created a second wave the public card would advertise the early-bird price after early bird closed and count stock in waves that had not opened. Refs #61. `build_nip52_event` now describes the wave a buyer can actually buy from: - several waves can be open at once, and a publisher has no one to ask which one the buyer wants (the purchase endpoint errors with "Please select a ticket wave"), so it advertises the CHEAPEST open wave — the price a buyer is able to obtain. Deviation recorded in docs/upstream-candidates.md. - with no open wave, `tickets_available` is 0 and never omitted: omission used to mean "unlimited", which #34/#62 removed as a concept. - `tickets_payment_methods` is scoped to the advertised wave too. It was derived from `event.allow_fiat` — the primary wave's — so it could offer a fiat rail while `tickets_allow_fiat` was absent and the purchase endpoint would refuse it. They are the same fact and now come from the same place. Wave boundaries are time-driven, and every republish we have is sale-driven, so nothing fires when early bird ends at midnight. Rather than add a scheduler, a publish records which wave it advertised (`nostr_published_wave_id`, m004) and the reconciliation sweep compares that against the wave that would be advertised now, setting `nostr_publish_pending` on a mismatch — reusing the existing retry path. NULL means "never published", which the sweep leaves alone so an upgrade does not republish the whole table on first boot. The selection rule lives in `models.advertised_ticket_wave` so the publisher and the drift detector cannot disagree about what is on the relay. 17 new tests; 114 pass. ruff, black, prettier clean; mypy error set still identical to HEAD's baseline.
This commit is contained in:
parent
d90a0f8322
commit
15c2276e57
10 changed files with 525 additions and 39 deletions
12
__init__.py
12
__init__.py
|
|
@ -139,12 +139,22 @@ def events_start():
|
|||
Quiet by design: on a healthy instance the query returns nothing
|
||||
and this logs nothing. It only speaks up when there is drift.
|
||||
"""
|
||||
from .crud import get_events_pending_republish
|
||||
from .crud import flag_wave_transitions, get_events_pending_republish
|
||||
from .nostr_hooks import publish_or_delete_nostr_event
|
||||
|
||||
await asyncio.sleep(REPUBLISH_SWEEP_FIRST_DELAY)
|
||||
while True:
|
||||
try:
|
||||
# Wave boundaries are time-driven, so nothing else flags
|
||||
# them. Done here rather than on a timer of its own: the
|
||||
# boundary is day-granular, so one sweep interval of
|
||||
# staleness is immaterial (aiolabs/events#61).
|
||||
moved = await flag_wave_transitions()
|
||||
if moved:
|
||||
logger.info(
|
||||
f"[EVENTS] Republish sweep: {moved} event(s) changed "
|
||||
f"ticket wave"
|
||||
)
|
||||
pending = await get_events_pending_republish()
|
||||
if pending:
|
||||
total = len(pending)
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue