Notifications: push, reply, schedule

Open this page in two browsers, pick the other user as recipient, send a message. Their tab pops a card; the value they click comes back as your live.push reply. Or schedule it 3 seconds out and watch the 6-field live.cron tick drain it.

Sending as Breezy Turnip (85a0077d)

Incoming (0)

Nothing yet. When someone pushes you a notification, the card appears here with reply buttons.

Send a notification

Recipient Schedule (0s of 30s max)

Scheduled (0)

Nothing pending. Set a schedule above to enqueue a notification.

Recent activity (0)

Each entry names the worker that handled that step, and marks how the push reached its recipient. Those are two different pieces of cluster machinery. Differing worker ids on a schedule and its fire mean the cluster-shared queue and the leader-gated cron did their job: one instance enqueued it, another drained it. The connection registry is not involved in that - its job is reaching a recipient's socket wherever it happens to be connected, and the badge is what reports it: relayed via cluster when the recipient was on another instance, same instance when no hop was needed. (One local instance shows one worker id and no relays.)

Nothing yet.

Server: sendNotification calls live.push({ userId }, 'demos:notification', {...}, { timeoutMs: 8000 }). The reply value (the recipient's button click) becomes the RPC return. NOT_FOUND means neither this instance's local push registry nor the cluster connection registry has an entry for that user; timeout means they were online but didn't reply within 8 seconds.

Client: onPush('demos:notification', handler) registers one handler at mount. Each push opens an unresolved Promise; the user's Got it / Dismiss click resolves it with { ack } and the value travels back to the sender.

Scheduler: a single live.cron('* * * * * *', ...) tick drains the in-memory queue every second (6-field cron schedule). Pushes inside the tick are fire-and-forget so a slow recipient can't block the next tick; per-push outcomes land in the activity stream when they resolve.