Instruction 08-notifications-for-downloads-failures-and-request: Reading

A notification pipeline should be treated as an operational system, not as a decorative feature. Download managers, media automation tools, and request applications often emit events independently. Those events may use different field names, retry policies, and authentication methods. A reliable design therefore separates event ingestion, normalization, policy, queuing, and delivery. Ingestion accepts an event but does not assume that the event is trustworthy or complete. Normalization validates a stable event identifier, an allowed event type, a timestamp, and an object-shaped payload. Policy then maps the event to a severity and audience. A successful download is usually informational and belongs in an activity destination. A failed download is actionable and belongs in an operations alert destination. Request creation may be informational, while approval or denial should normally be routed to the audience responsible for request status.

Delivery must not be confused with event acceptance. A remote notification provider can be unavailable even though the source event is valid. A durable outbox lets the system acknowledge and retain valid work before a separate delivery worker contacts the provider. Production workers should use bounded retries, increasing delays, random jitter, explicit connection and response timeouts, and a terminal failure state. Retrying forever creates hidden queues and repeated messages. Providers may also redeliver source events, so each event needs a stable identifier. Deduplication state must be written durably enough to survive process restarts. The lab demonstrates this by recording accepted identifiers in a local state file and using an atomic replacement operation when updating that state.

Notification content must be considered untrusted and potentially sensitive. Payloads can contain provider tokens, passwords, internal paths, usernames, request notes, or media names. Only fields needed by the recipient should be included. Secrets must be redacted before writing the outbox, not merely hidden in a user interface after storage. Malformed input also requires care: storing the complete rejected record can preserve a secret indefinitely. The lab records a digest, line number, and error instead of copying malformed input. Finally, a useful notification answers three questions: what happened, how important is it, and what action is expected? Severity, destination, and concise context should support those questions. Every notification rule should be tested for valid input, duplicate delivery, malformed input, and secret leakage before it is connected to a real provider.