A capability stays maintainable only when the team can explain every state, retry, and piece of residual data—not merely show one successful run. A final-only success rate mixes refusal, abandonment, technical failure, and lost telemetry. Every attemptId needs a start and exactly one terminal outcome.
Observability should locate the failing stage, affected sessions, and whether impact is growing. Events use allowlisted low-cardinality dimensions; payloads, secrets, and complete network identity stay out.
Questions the design must answer
Turn the important choices into durable contracts: validate inputs, assign state ownership, define cleanup, and specify fallback for older peers. Later optimization must not change those semantics.
- Emit from a client stage machine with server-validated enums; record relative duration, path type, and low-cardinality errors without SDP, addresses, or peer IDs.
- Bound every input by size, count, and time, returning a stable actionable error code when a budget is exceeded.
- Retries need an idempotency key, backoff, and deadline; after the deadline create a new task instead of reviving old callbacks.
The delivery standard for Instrumenting the Connection Funnel from Click to Usable DataChannel is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Edge cases are part of the feature
Boundaries turn hidden assumptions into incidents. Weak networks, refresh, concurrency, and capacity need combined coverage because retries can hide each one in isolation.
- Independent callback events duplicate and reorder stages, retries change denominators, and permanent user IDs exceed diagnostic need.
- Fixing only the UI leaves queues, locks, or expired credentials for the next operation to inherit and fail again.
- Without backpressure or quota, a slow consumer raises memory, queue depth, and tail latency until unrelated users are affected.
Prove that it works with evidence
Observe both endpoints, persisted records, and operational signals during verification. One button state or one successful response cannot prove the complete loop.
- Create golden traces for success, refusal, timeout, TURN failure, and refresh recovery; each attempt follows one valid path and funnel counts reconcile.
- Run one hundred start, fail, retry, and cancel cycles; handles, listeners, queues, and temporary data must return to baseline.
- Before release, record success rate, p50/p95/p99 latency, error classes, and resource high-water marks with explicit rollback thresholds.
The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.