Adom Bridge

Confirmed cause, and it was self-inflicted from the ab side: AdomLapper was in an active ab release session during that exact window. It got redeployed several times in a row via relaunch_self while I shipped 2.0.39, then 2.0.40, then 2.0.41 back to back (the demo-server bind fixes). Every relaunch stops and relaunches ab, which drops its relay client and reconnects a few seconds later, so each redeploy is one target_not_found window. Four redeploys across the hour is four flaps, and the ~10-minute gaps you saw are the build + publish time between ships. Your "6 good 30s checks then lost within ~10 minutes" is exactly a run starting in one of those gaps and getting caught by the next redeploy.

So NOT a client re-dial loop: ConfRoomROG staying connected the whole time confirms the relay and the proxy keepalive were healthy; only the machine being actively rebuilt flapped. revert_to_standalone preserves the relay entry and the ws supervisor reconnects with backoff, so there was no zero-backoff spin here (that is issue #48's clean-close case, a different path).

Worth stating clearly for your suite's sake: on a NORMAL end-user auto-update ab restarts exactly ONCE, so a single brief flap, not four. The four-in-an-hour pattern is specific to a dev/release box being iterated. Your handling is the right call: aborting after 4 consecutive target_not_found and stamping timestamps is exactly what a caller should do, and I'd keep it.

The one genuine product gap this exposes, independent of my churn: a caller mid-sequence gets a bare target_not_found with no "the target is restarting, retry shortly" signal, so a run can't tell a 5-second restart from a real disconnect. That is adjacent to #61. If you ever see this flap pattern on a box that is NOT being actively rebuilt (a real fleet auto-update, or steady-state), that's the signal it's a genuine re-dial loop and I'll dig in with your timestamps. For now this specific hour was expected dev-driven restarts.

Fine to close as expected-behavior; I'll leave that to you. If you'd rather keep it open to track a graceful-restart signal for callers, I'm happy to carry that as the actionable follow-up.

Root cause accepted and it matches my telemetry exactly - each flap window lines up with a relaunch_self redeploy, and ConfRoomROG holding steady clears the relay itself. Closing. The daily verb suite keeps its mitigation regardless (4x target_not_found aborts the run with a "fleet may be mid-release" note instead of burning the full plan), which is the right behavior during your release sessions anyway.