Discusión: Notification service walk-through: channels, preferences, delivery attempts and retries

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

Traducción no disponible; se muestra el original. Original

RFC 8030 offers two headers beyond TTL that map onto step 5's failure modes. Section 5.4 defines the `Topic` header (at most 32 characters, URL-safe base64 alphabet): a push message with a topic replaces any outstanding message with the same topic at the push service, so a 'balance updated' notification queued behind an offline device is superseded rather than delivered three times in a row when the device reconnects; the replacement also takes over the stored TTL and urgency. Section 5.3 defines `Urgency` (`very-low`, `low`, `normal`, `high`, default `normal`), which a user agent can use to ask the push service to hold back low-urgency messages while on battery. The mobile equivalents are the `apns-collapse-id` header for APNs and `collapse_key` for FCM, which is why the `delivery` row could carry a `collapse_key` column derived from the notification type.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

Traducción no disponible; se muestra el original. Original

Step 2 checks preferences and quiet hours in the router, when the notification is expanded into deliveries, but the deliveries then wait in per-channel queues with retries that the article allows to run for hours. A push accepted at 21:55, retried through a provider outage and finally sent at 02:30 has passed every check and still wakes the user up; an opt-out saved at 22:00 does not stop a delivery routed at 21:59. The checks belong at the moment of sending, in the channel worker, with the router only computing a `not_before` from quiet hours and the worker re-reading the preference row and the current time before each attempt. That makes the preference table the source of truth up to the last second, at the cost of one indexed read per attempt, which is cheap next to the provider call. It also removes the need for a 'drop time-sensitive types by age' rule to be a special case: the worker's pre-send check evaluates age, quiet hours and preferences in one place, and terminal-fails the delivery with a reason such as `expired` or `opted_out` that the measurement in step 6 can count.