Skip to content
Code Recycle

Component · for humans & their agents

Realtime Connection State

verified · first-partyactively maintained$0 during beta (was $49)

When a live voice connection degrades, the one thing that must never happen is the user losing the ability to type. A connection-state machine with a one-way fallback ladder — streaming to reconnecting to REST to typed-only — where every state is exhaustively checked at compile time.

by Code Recycle

Get it free — beta

Every claim on this page is refundable if it is untrue — refund policy.

Building it yourself: ~2h of agent time across about 4 attempts. You would catch a mistake here yourself, so this is genuinely a question of whether you would rather spend the quota. $49.

15 tests. Pure, zero runtime dependencies, ESM. No WebSocket, no timers, no DOM — the same

The bug this exists to prevent

Realtime voice fails in ways that are individually recoverable and collectively confusing. The usual implementation is a boolean connected, then a second flag for reconnecting, then a third for "degraded" — and the combinations nobody enumerated are where users get stranded.

The specific failure worth naming: a connection that drops while already in a fallback mode. A naive reconnect handler sends it back to reconnecting, which then fails again, and the user oscillates between two broken states instead of settling into the one that works.

Rule 1 — degradation is one-way and ordered

streaming → reconnecting → fallback_rest → fallback_typed, and never backwards on a failure. A second-order failure while already in fallback_rest degrades further, to fallback_typed. fallback_typed and ended are floors: a further disconnect is a no-op, never a crash and never a regression upward.

Recovery is a separate, deliberate act. Automatic promotion on a single good signal is what produces the oscillation.

Rule 2 — typing is the bright line

allowTypedInput is true in every single state, and there is a test asserting exactly that across all of them. Whatever else has failed, the user can still type.

This is the rule most easily lost in a refactor, because disabling input during "reconnecting" looks like correct UI hygiene. It is the moment a user with a broken microphone is locked out of the only channel still working.

Rule 3 — an unhandled state must throw at compile time

The exhaustive never check means adding a state without updating every switch is caught by tsc, not discovered live mid-session. There is a test proving the never branch throws rather than falling through — a dead branch in normal use, asserted so it stays dead.

What this does NOT do

No transport. No WebSocket, WebRTC, retry timers, audio, or transcription. It decides what state you are in and what is permitted there; you own the sockets.

It does not implement recovery — promotion back up the ladder is a caller decision, deliberately.

Verified

15 tests: every state described without throwing, allowTypedInput true in all states, ordered degradation, exhausted reconnect attempts, second-order failure degrading further, floor states absorbing further disconnects, and the never branch throwing.

Not covered: no test drives a real transport, and there is no timing or flap-detection test — how long to wait before declaring a drop is yours.

01Capabilities

Does

  • + Error monitoring & alerts
  • + Voice input capture
  • + Reliability

Doesn’t

  • No exclusions declared

02Requirements & stack

Depends on

No declared dependencies

Credentials needed

None declared

Stack

03Community

No endorsements yet

No verified confirmations yet — be the first.

Confirmations come from verified purchasers, installers, vetted reviewers, or an installation outcome your org reported through the agent tools. They grade quality — security is verified separately, and community votes can never override the security gate.

Open an issue

Sign in to confirm — weight comes from verified usage, not vote count.

Nobody has reported anything yet — a success counts as a report too.

04Trust Passport

Full passport →
–/100

0/0 automated components pass. An automated score is never a security guarantee.

✓ Verified · first-partyreviewed Sep 20, 2026 · re-verification due Dec 19, 2026
  • publisher identity Publisher status verified; 1 verification(s) on file
  • malicious pattern scan No known malicious-behavior patterns across 7 source file(s) plus listing text
  • capability contract All 0 observed capability reference(s) match the declared manifest
  • agent safety scan No injection patterns in agent-readable content
  • provenance No release signature or provenance attestation
  • behavioral sandbox Not performed in this environment — requires the production isolated runner (docs/sandbox-requirements.md). No untrusted code is ever executed on the application host.

Every listing must pass this review before it can be sold, and it is re-run on every release. Verification describes what we checked — it is not a guarantee that the software is safe.

VersionChannelReleasedNotes
0.1.0stableAug 11, 2026Initial extraction.