MCP notification streams now reconnect after a server drop or redeploy instead of silently going dead.
What's wrong with this entry?
A watcher keeps the subscriptions/listen stream alive on modern-era MCP connections, so a dropped or redeployed server no longer silently ends notification delivery.
- remote drops are retried on a delay ladder; a graceful server close waits out a redeploy grace window before re-listening
- gives up once the ladder is exhausted
- after a successful reopen it re-fetches tools, prompts and resources lists for whichever listChanged capabilities the server advertises
- tools/list gained a bounded retry loop using
cacheMode: "refresh" - telemetry event tengu_mcp_listen_reopen reports outcome (
opened_from_zero,reopened,budget_exhausted,gave_up), attempt count and trigger - the path only runs on modern connections, that is behind the protocol-negotiation gates
subscriptions/listen closed gracefully (server shutdown); re-listening after the redeploy grace window
Strings lifted out of the shipped bundle, so the claim above can be checked against them.