@urun-sh/core 0.3.4 → 0.3.6

package/CHANGELOG.md

@@ -2,6 +2,28 @@
 
 ## Unreleased
 
+- **BREAKING: `WtMicUplinkHandle` and `WtCamUplinkHandle` require
+  `deliveredDatagrams(): number`; `WtUplinkSink` requires `delivered(): number`.**
+  A consumer that supplies only `setSource()` (and `requestKeyframe()` for the
+  camera) to `TransportSession.wtMicUplinkSeam` / `wtCamUplinkSeam` no longer
+  type-checks. Implementors report the datagrams QUIC has ACCEPTED from that
+  lane. There is deliberately no optional-with-fallback form: a lane that
+  cannot answer "did anything actually leave?" is the bug being removed
+  (urun-sh/urun-infra#2053 — `isProducingMedia` claimed a live microphone from
+  handle presence plus `MediaStreamTrack.readyState`, so the SDK reported a
+  healthy mic through an entire session in which nothing was transmitted).
+  Migration: return a per-lane counter incremented when that lane's datagram
+  write resolves. `WtUplinkSink` is internal — it is not exposed by the package
+  entrypoints — so only the two handle types affect external implementors.
+
+- **Media liveness is level-triggered, and a sender sequence RESTART resyncs
+  instead of wedging the leg forever** (urun-sh/urun-infra#2053). Both media
+  lanes kept a monotonic high-water mark with no RFC 3550 §A.1 restart rule, so
+  a sender that restarted its sequence space was discarded for the life of the
+  session — silently, and on video before the keyframe bit was even read. The
+  decode-stall watchdog is no longer one-shot, uplink datagram write rejections
+  are no longer swallowed, and publication requires delivery evidence.
+
 - **WT uplink lanes now share ONE datagram writer (`getWriter` lock).**
   `WritableStream.getWriter()` LOCKS the stream — the WHATWG contract is one
   writer at a time. `WebTransportSession.start()` built its uplink sink by
@@ -16,6 +38,37 @@
   `releaseLock()`-ed on stop/death. The pre-existing fakes handed back a fresh
   writer on every call, hiding the double-acquire; the new
   `wt-uplink-writer-lock.test.ts` fake implements the real lock contract.
+- **A dead WT-only leg now LOUD-FAILS instead of silently "failing over" to a
+  transport that was never dialled.** On a fully-granted leg the negotiator
+  calls `webRtcDial.skip()` — no `RTCPeerConnection`, no mediasoup Device, no
+  server media transports. When QUIC then died mid-session, `armFailover`
+  re-drove the deferred dial fire-and-forget and immediately awaited
+  `startWebRtc()`, whose `WebRtcSession.start()` awaits a `track` event that a
+  never-dialled leg may never receive. The await never settled: `session` was
+  never reassigned (`activeTransport` kept reporting the DEAD `'webtransport'`),
+  `transport.established` was never notified, `onTransportChange` never fired,
+  and NOTHING reached the app — a black pane behind a misleading
+  `quic died mid-session, failing over to webrtc` line (qwen-avatar
+  2026-09-01). The failover is now bounded by `webRtcFailoverDeadlineMs`
+  (default 10s); on expiry the negotiator drops the stale session
+  (`activeTransport === null`), skips the false `transport.established(webrtc)`
+  notify, logs a specific `media transport lost — …` error naming the WT-only /
+  no-RTCPeerConnection condition, and surfaces it through the new
+  `onMediaTransportLost` seam (plumbed through `negotiateDialTransport`, which
+  also clears the stale track overrides and arms the WT retries). The warn line
+  itself no longer claims a WebRTC leg exists on a WT-only leg. The abandoned
+  WebRTC session is retained synchronously and stopped DIRECTLY on expiry (a
+  cleanup chained off the abandoned `start()` promise never runs in exactly the
+  never-settles case the deadline exists for, leaking the peer connection for
+  the life of the page), and both the adopt and the give-up paths are guarded
+  against a `disconnect()` — or a background WT re-upgrade — that landed while
+  `start()` was in flight.
+- **A mid-session WT death no longer masquerades as a failed negotiation.**
+  `engage()`'s `await media.firstMedia` rejection escaped to the connect-path
+  catch, so a death minutes after a SUCCESSFUL dial wore the
+  `transport negotiation unavailable, staying on webrtc` line and re-drove the
+  deferred WebRTC dial a second time. It is now caught where it belongs; the
+  negotiator's failover path owns the death.
 
 ## 0.3.0