- Shipped
- September 8, 2026 at 12:23 AM UTC
- Author
- Kamo
- Commit
- ee2981d
The relay subscribed once, from @PostConstruct, and never again. When VOIPService's voip.> stream did not exist — which it did not — both replicas logged exactly one line each and then relayed nothing, ever: [VoipRelay] Failed to subscribe to voip.> subject: [SUB-90007] No matching streams for subject. No live texts, no unread badge, no call events, no voicemail, no mobile push, on a pod that otherwise looked perfectly healthy. Creating the stream fixes the cause but not those pods: they had already made their one attempt. The ordering is not fixable either. VOIPService creates the stream when VOIPService boots; MediaService subscribes when MediaService boots. Nothing sequences two deployments, so "the stream exists by the time the relay starts" is a coin flip on every cluster restart. The relay has to tolerate the stream not being there yet. ensureSubscribed() is now idempotent and there are three doors into it: the original @PostConstruct, a 30s retry while unbound, and — the one that matters — a member subscribing to /topic/voip/*, which means a real person is sitting in front of an SMS window waiting for frames this pod is not receiving. isRelayBound() asks whether the subscription is ACTIVE, not whether subscribe() returned. An ephemeral consumer is reaped after its inactiveThreshold, and a pod holding a handle to a consumer NATS has forgotten looks subscribed and receives nothing — the same silence as never having subscribed, with none of the evidence. That case rebinds too. The first failure logs at ERROR and says what is inert because of it; the retries log at debug, so a stream that does not exist yet does not fill the log every 30 seconds.