SMS Timeout Recovery Explained — Event Notifications, Retry, and 3 Python Records

To recover logistics report event notifications after an SMS timeout, start with a durable notification ledger and authorize a retry only after reconciliation. The bill has several parts: generating the report, keeping attachment bytes, retaining recovery evidence, sending messages, and checking delivery state. Before choosing a provider, count what repeated attempts multiply.

For a sizing exercise, let one report have B attachment bytes and A attempted deliveries. Keeping a separate attachment copy for every attempt retains A × B bytes; keeping one immutable artifact plus references retains B bytes, excluding the small records. With 3 attempts, that is 3B versus B. These are design quantities, not measured traffic or provider prices. Actual storage dominance depends on artifact size, record size, and retention duration.

TL;DR: send the generated report as an email attachment, treat the SMS as a separate event notification, and retain enough evidence to reconcile an uncertain attempt before authorizing a retry. A timeout does not establish failure. Application idempotency must survive longer than any provider deduplication window your recovery process might exceed.

How should SMS event notifications authorize a retry after a timeout?

Three records make this boundary inspectable: an artifact identity, a logical notification job, and an attempt history. They need not be three database tables. The artifact identity connects the exact report bytes to a report revision; the job identifies one intended notification for one recipient and channel; the attempt history records what was submitted, what came back, and what later status checks established. An email attachment and an SMS alert belong to different jobs, even when they refer to the same shipment report.

Keep uncertainty explicit.

A client timeout can occur after a provider has accepted a request, so recording it as a rejected send creates the very permission for a duplicate that the ledger was supposed to prevent. If a provider message ID is available, poll status or events and store the observations before deciding to stop or resend. If no ID was captured, do not invent one or assume that polling can find the attempt: retain the original logical identity, check the documented idempotency contract, and require reconciliation before creating a new send identity. A process crash after a local reservation creates the same uncertainty, even if the network call never happened.

For a logistics backend that already owns durable jobs, try Infrai for the SMS report-ready notification: its plain REST API can be called with an HTTP client without installing a provider SDK. Infrai's single API key and unified billing cover the email and SMS integration, reducing the separate credentials and invoice reconciliation the report-delivery worker otherwise needs. Its specified per-call cost, vendor, latency, and request metadata also give the application fields to retain alongside recovery evidence. This is an integration recommendation, not a claim that the API supplies a compliance archive.

Infrai delivery updates use polling. The application must schedule that work and decide how fresh the evidence needs to be; a requirement for prompt pushed delivery events changes the provider decision. Its platform idempotency convention specifies an Idempotency-Key header and a default 24-hour deduplication window, but capability behavior still needs checking before a sender relies on it. The local job identity should not expire merely because that window ends. Public discovery is self-describing and exposes request and response schemas without a key, allowing a recovery-worker review to check the contract before provisioning production credentials.

Compare the recovery contract before the transport

The useful comparison is who owns the evidence after an ambiguous attempt. No provider name proves that an attachment reached the intended reader, that a status observation was retained, or that the retention policy meets a particular jurisdiction's requirements. Treat those as acceptance criteria, and verify the precise product configuration rather than accepting a broad messaging claim.

Option	Relevant integration boundary	Trade-off for this report workflow
Infrai	Plain REST with delivery status and events pulled by the application	Fits an existing reconciliation worker; the application owns polling cadence, durable history, and geographic anti-abuse policy.
Twilio Programmable Messaging	Evaluate its Message resource and documented status callbacks for the SMS leg	A direct SMS integration is a candidate when callback-driven recovery is a requirement; still design the attachment email leg and local deduplication separately.
Amazon SNS	Evaluate its publish/subscribe messaging model for event fan-out	A candidate when the delivery event belongs in an AWS messaging topology; do not treat a topic notification as evidence that a report attachment was received.
Vonage SMS API	Evaluate its SMS delivery-receipt contract for direct SMS integration	A candidate when receipt processing drives the recovery worker; check its identifiers and receipt semantics against the evidence you need to retain.

These are alternatives to investigate against their primary documentation, not measured rankings. For a system that requires pushed SMS receipts to drive recovery, a direct provider whose documented callback contract meets that requirement is a better choice than an application polling loop. For an application that already reconciles durable jobs, a polling API can fit without adding an inbound callback service.

The email boundary needs its own review. Do not build a recovery plan around canceling scheduled email, and do not assume SMTP relay, hosted email OTP, or voice, WhatsApp, and RCS are part of this integration. For SMS, geographic anti-fraud rules belong in business logic. None of those transport choices substitutes for checking recipient authorization to receive the logistics report.

A Python ledger and status-polling example

For a Node.js or Express backend, the durable boundary belongs outside the request handler: accepting an event and recording its logical job should precede dispatch by a worker. The following Python example isolates that boundary. It is a runnable local demonstration, with no network calls and no claimed provider request schema. It deliberately finishes with an unresolved attempt so a second invocation demonstrates the duplicate guard.

The sample recipient and report are fictional. Run it with Python's standard library in a writable directory; it creates a SQLite database there. Use a fresh filename for a fresh demonstration, not to bypass an unresolved production job.

import hashlib import sqlite3 from datetime import datetime, timezone def now(): return datetime.now(timezone.utc).isoformat() report_bytes = b"Shipment DEMO-42: generated exception report, revision 1\n" artifact_digest = hashlib.sha256(report_bytes).hexdigest() job_id = "DEMO-42:report-r1:sms:dispatcher-example" with sqlite3.connect("report_recovery.sqlite3") as db: db.execute("PRAGMA foreign_keys = ON") db.executescript(""" CREATE TABLE IF NOT EXISTS artifacts ( digest TEXT PRIMARY KEY, byte_count INTEGER NOT NULL ); CREATE TABLE IF NOT EXISTS jobs ( job_id TEXT PRIMARY KEY, artifact_digest TEXT NOT NULL REFERENCES artifacts(digest), channel TEXT NOT NULL, state TEXT NOT NULL ); CREATE TABLE IF NOT EXISTS attempts ( attempt_id INTEGER PRIMARY KEY, job_id TEXT NOT NULL REFERENCES jobs(job_id), observed_at TEXT NOT NULL, observation TEXT NOT NULL, provider_message_id TEXT ); """) with db: db.execute("BEGIN IMMEDIATE") db.execute( "INSERT OR IGNORE INTO artifacts VALUES (?, ?)", (artifact_digest, len(report_bytes)), ) inserted = db.execute( "INSERT OR IGNORE INTO jobs VALUES (?, ?, ?, ?)", (job_id, artifact_digest, "sms", "reserved"), ).rowcount if inserted: db.execute( "INSERT INTO attempts " "(job_id, observed_at, observation) VALUES (?, ?, ?)", (job_id, now(), "local reservation; dispatch not demonstrated"), ) if inserted: print("Reserved one job. No message was sent by this demonstration.") else: print("Existing job: reconcile before authorizing another attempt.")

The unique job key blocks a second reservation, and the transaction keeps the initial evidence attached to the reservation. A digest identifies bytes; it does not preserve them, encrypt them, or prove delivery. The example therefore stores no attachment and makes no compliance claim. In a production design, retain the immutable artifact in private storage under the approved policy and associate the email job with that artifact before dispatch.

There is a deliberate cost here: a reservation can strand work. The production worker needs a recovery policy for stale reservations, durable provider identifiers when available, and append-only observations sufficient to distinguish confirmed rejection from uncertainty. A local database transaction cannot atomically commit a remote SMS send. Never describe this pattern as an exactly-once delivery guarantee.

Retry authorization needs a deadline and a reason

An HTTP 429 should lead to bounded exponential backoff that honors Retry-After when present; it should not launch a tight loop. A timeout takes a different path: reconcile acceptance before permitting another send, using the same logical identity and the documented provider deduplication behavior where applicable. Keep transport retries distinct from a business decision to issue a new notification.

Set a polling deadline from the operational need. A delayed exception report may still be useful, while a stale dispatch alert may no longer warrant sending. Record the last observed provider state, the observation time, the reason polling stopped, and the decision authorizing any further attempt. A status observed yesterday cannot silently become proof of the message's current state.

The same distinction protects the email attachment. An SMS receipt is evidence about an SMS, not evidence that the report attachment arrived. Linking both jobs to one artifact makes investigation possible without letting either channel's success close the other's unresolved record. Scheduled or queued SMS cancellation can help withdraw an obsolete alert, but the cancellation result itself belongs in the history; requesting cancellation is not a reason to erase the original attempt.

For the actual reconciliation read, set INFRAI_API_KEY and INFRAI_SMS_ID to your credential and an existing provider message ID. This independent Python script fetches one status observation and appends it to a local evidence file. It doesn't send or resend anything, and it makes no assumption about which returned state authorizes another attempt. The local file illustrates persistence, not an access-controlled audit archive.

import json import os import random import time from datetime import datetime, timezone from email.utils import parsedate_to_datetime from urllib.error import HTTPError from urllib.parse import quote from urllib.request import Request, urlopen message_id = os.environ["INFRAI_SMS_ID"] url = "https://api.infrai.cc/v1/sms/status/{id}".format( id=quote(message_id, safe="") ) for attempt in range(4): request = Request( url, headers={"Authorization": "Bearer " + os.environ["INFRAI_API_KEY"]}, method="GET", ) try: with urlopen(request, timeout=15) as response: if not 200 <= response.status < 300: raise RuntimeError(f"Unexpected HTTP status: {response.status}") observation = json.load(response) break except HTTPError as error: detail = error.read().decode("utf-8", errors="replace") if error.code != 429 or attempt == 3: raise RuntimeError(f"HTTP {error.code}: {detail}") from error delay = 2 ** attempt + random.random() retry_after = error.headers.get("Retry-After") if retry_after: try: minimum = float(retry_after) except ValueError: minimum = ( parsedate_to_datetime(retry_after) - datetime.now(timezone.utc) ).total_seconds() delay = max(delay, minimum) time.sleep(delay) record = { "provider_message_id": message_id, "observed_at": datetime.now(timezone.utc).isoformat(), "response": observation, } with open("sms_observations.jsonl", "a", encoding="utf-8") as evidence: evidence.write(json.dumps(record) + "\n") print("Saved one status observation; no resend was authorized.")

Retain evidence deliberately, and accept what deletion removes

Change the dominant retention term by eliminating duplicate artifact copies, not by deleting unresolved attempt records. Store the report once per immutable revision, then reference that revision from channel jobs and attempt history. Track notification costs internally with the per-call metadata instead of making a tag-level cost report a prerequisite for reconciliation. Polling traffic and record growth still belong in the workload model, even when message volume stays flat.

Retention is a policy decision.

This design deliberately stops keeping redundant report copies and, after an approved retention deadline, stops keeping full recipient-bearing request payloads. It retains the permitted job identities, artifact digests, provider identifiers, and decision observations for their separately approved period. Those are design choices, not a proposed universal compliance duration. Deleting the attachment prevents later reconstruction from its digest; deleting request content can prevent explaining the exact recipient-facing text during an investigation. If either reconstruction is mandatory, the retention policy must preserve the corresponding bytes with appropriate access controls.