[🐛 Bug]: PusherClient unbound in recover_strategy

[diegovb-sys]

Describe the bug
The migration process of the "standard" alert flow to the recover strategy process has not been completed. Hence, there are some issues related to the pusher process once the alert is recovered from the maintenance window.

Expected behavior
Follow the same standard flow, for that it's mandatory to copy the same process that in __handle_formatted_events function.

[dosubot]

The issue is that the recover_strategy process does not properly bind or use the PusherClient, so notifications (like "poll-alerts") are not triggered when alerts recover from a maintenance window. In the standard alert flow (as seen in the __handle_formatted_events logic), PusherClient is obtained via get_pusher_client() and used to trigger a "poll-alerts" event on the tenant's private channel, ensuring clients are notified to poll for alerts. To resolve this, you should replicate the PusherClient logic from __handle_formatted_events in the recover_strategy process so that notifications are sent consistently after alert recovery, matching the standard flow behavior. You can see the expected notification flow and PusherClient usage in the standard handler here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}