- Shipped
- August 11, 2026 at 4:09 PM UTC
- Author
- Kamo
- Commit
- f3a7283
A durable JetStream consumer keeps the filter subject it was created with for the life of the stream. When the owning code later changes that subject, jnats refuses the binding with "[SUB-90011] Subject does not match consumer configuration filter" and keeps refusing it forever, so the subscription is permanently dead with nothing but a caught exception to show for it. EmailService is living that failure right now. Widening its per-member consumer from email.inbox.<addr> to email.*.<addr> left eight members pinned to consumers still filtered on email.inbox.<addr>; their NATS -> STOMP relay never comes up, so no unread snapshot and no mailbox-change event ever reaches the browser and the nav mail badge sits on whatever the one-shot REST fallback read at page load. Reading mail changes nothing on screen. The two members whose consumers were created after the change work fine, which is what made it look like the mark-read call was at fault. subscribe() now reads the existing consumer's filter and drops the consumer when it differs, so the next subscribe recreates it correctly and every stuck member heals on their next connect. Recreating is free here because these consumers are built with DeliverPolicy.New: a fresh one starts at the next message, which is where a surviving one would have been anyway.