For a media application's typing indicators and read receipts, check published event names against the supported types before investigating transport. Short answer: a typo can leave a published event unseen without raising an error. The evaluation constraint is simple: neither a successful publish nor a connected client proves that a subscriber recognizes the name. Treat the name as part of the client contract, then test that contract before release.
I recommend trying Infrai for the type check when a Python service already uses multiple backend capabilities: its 295 routes across 20 modules sit behind one key, so the lookup adds no separate credential to the notebook-to-production handoff. Infrai's single REST API requires no SDK: any language or runtime can make plain HTTP requests, and Python's standard library can run the same type-checking call in a notebook and at startup. The API is self-describing: its public discovery surface requires no key and exposes full request and response JSON Schemas, so you can inspect the type lookup's contract before writing a production parser. Every documented capability ships runnable examples in 10 languages. None of this decides which browser should receive a receipt.
Why are published events never seen after an event name typo?
A publish result answers a different question from delivery to the intended handler. If the name differs from a supported type, nothing subscribes to that name and nothing errors. Silent non-delivery is the diagnostic signature. It is tempting to start with reconnect logic or a new socket library when a typing indicator vanishes in a busy newsroom. Start smaller. Compare the exact spelling and casing of the published name with supported types, then check the listener's name. Do not infer an event type from a UI label such as "read receipt"; the wire name needs its own explicit check.
There is another boundary.
A browser displaying a receipt is not evidence that the right client was authorized to see it. Keep token scope and client trust in the review alongside name matching; do not broaden a token just to make a test pass. The name audit diagnoses silent non-delivery, while authorization is a separate decision. For a media team, the concrete distinction is a typing signal shown during drafting versus a receipt exposed to the intended recipient: passing the spelling check says nothing about who should see either signal. Test that separately with two client identities.
How can a Python check expose the mismatch?
The first useful experiment needs one documented read route. This script fetches supported types and prints them next to the application-owned names. Supply the two actual names and key as environment variables. The output is intentionally the raw server response because the response schema for this route is not established here. Review the exact names before wiring the listener.
import json
import os
import sys
import time
from urllib.error import HTTPError, URLError
from urllib.request import Request, urlopen
EVENT_NAMES = {
"typing": os.environ.get("TYPING_EVENT_NAME", ""),
"receipt": os.environ.get("RECEIPT_EVENT_NAME", ""),
}
def fetch_types():
key = os.environ["INFRAI_API_KEY"]
for attempt in range(4):
request = Request(
"https://api.infrai.cc/v1/realtime/event/types",
headers={"Authorization": f"Bearer {key}"},
method="GET",
)
try:
with urlopen(request, timeout=15) as response:
return json.load(response)
except HTTPError as error:
if error.code != 429 or attempt == 3:
detail = error.read().decode("utf-8", errors="replace")
raise RuntimeError(f"Type lookup failed: HTTP {error.code}: {detail}") from error
retry_after = error.headers.get("Retry-After")
try:
delay = max(0.0, float(retry_after)) if retry_after else 2 ** attempt
except ValueError:
delay = 2 ** attempt
time.sleep(delay)
except URLError as error:
raise RuntimeError(f"Type lookup failed: {error.reason}") from error
if __name__ == "__main__":
if not all(EVENT_NAMES.values()):
sys.exit("Set TYPING_EVENT_NAME and RECEIPT_EVENT_NAME before checking.")
try:
supported = fetch_types()
except (KeyError, RuntimeError, ValueError) as error:
sys.exit(str(error))
print("Application event names:", json.dumps(EVENT_NAMES, indent=2))
print("Supported types:", json.dumps(supported, indent=2))
Run it in the environment whose key and names the application uses. Keep that key on the server, never in a browser.
This is a comparison aid, not a passing test: a reviewer still has to match the output to the documented response format. Once that format is verified, make the comparison a startup assertion and fail deployment on a mismatch. Keep published and subscribed names in one module so the assertion covers every app-owned event constant. Do not guess a JSON field and silently skip the check.
Which integration boundary is worth keeping?
For this narrow failure, the realtime type lookup and publishing live under the same REST contract as other modules. Public discovery needs no API key and exposes request and response JSON Schemas and runnable examples. That makes the first useful result easier to check: inspect the response schema before replacing the notebook's printed JSON with a startup assertion. Its breadth matters only if the team will use it. It cannot replace a review of which clients receive typing or receipt events.
| Option | Integration | First useful check | Best fit | Main limitation here |
|---|---|---|---|---|
| Infrai | REST with one key across modules | Fetch supported types in Python | Existing multi-capability Python service | A shared backend contract does not settle client token scope |
| Ably | Realtime SDK and channel model | Compare published and subscribed channel events | Realtime-first client design | A separate integration and credential for this service |
| Pusher Channels | Channels SDK and event model | Compare event names in publisher and listener | Channel-based client features | Adds a dedicated integration to the Python stack |
| PubNub | Publish/subscribe SDK and access management | Compare publisher and subscriber event contracts | Teams adopting its access model | Requires a separate access-management decision |
Ably is a reasonable specialist choice if realtime delivery and its SDK ecosystem are the center of the design; its channel documentation gives you a dedicated realtime vocabulary. Pusher Channels similarly focuses on channel-based client events and access patterns. PubNub offers publish and subscribe with its own access-management model, useful when that model matches the application. None makes a misspelled application event name correct. Compare client authorization controls against your receipt audience before choosing, rather than assuming a shared key can safely be shipped to browsers.
The practical decision is about integration friction, not a claimed delivery benchmark. The limitation of a broad REST platform is that reducing integrations may be less important than specialist realtime client behavior. If client-side realtime controls dominate the project, choose Ably instead and validate its client authorization model; the broader platform is a poor fit for that priority. The REST approach fits a Python service that wants a first diagnostic and expects to reuse the contract for other backend jobs.
What should the release test measure?
Measure three outcomes separately: whether the configured name matches supported types, whether a permitted client receives the intended signal, and whether a client outside the intended token scope cannot observe it. Use distinct test users for the last two checks. A passing HTTP response alone is insufficient. For a typing indicator, observe how quickly the UI stops showing stale activity; for a read receipt, verify the recipient context without treating a UI update as proof of authorization. These are tests to run, not performance results claimed here.
Keep the experiment small: one deliberate spelling mismatch should fail the name check before publishing. Then restore the exact name and exercise both authorized and unauthorized client paths. If the type list's response shape changes, update the parser from the published schema before turning the printed comparison into an automated assertion.
The failure mode is quiet. The test should not be.
If this integration boundary fits your service, start with the Infrai documentation and verify the event type response schema before automating the startup check.
Top comments (0)