Handle FCM events without ding IDs - #540

Brief follow-up after a couple of weeks: this fix remains in production use and ID-less FCM events are being handled correctly without the repeated callback failures. It has also since been referenced from Home Assistant Core issue #177118. Happy to adjust the fallback-ID approach if preferred.

Seeing this too on Home Assistant Container 2026.9.1 with ring-doorbell 0.9.14 and Python 3.14. Same KeyError: 'id' at event["ding"]["id"] in _get_ring_event, followed by Unexpected exception calling notification callback. It was also happening before the HA update.

+1 for this fix. Keeping those notifications flowing through to HA would be useful so motion/doorbell events don't get dropped. I haven't tested the patch yet.

Another confirmation from Home Assistant 2026.9.1 with ring-doorbell==0.9.14, plus one detail I have not seen in this thread: the failure is self-perpetuating, so the symptom is not a single missed event but a listener that stays dead until someone intervenes.

What happened here on 2026-09-11: three notifications from the previous morning were still sitting unacked in the FCM queue. They were replayed on every connect, _get_ring_event raised KeyError: 'id' on each one, and firebase-messaging counted three sequential NOTIFY errors and shut the receiver down (abort_on_sequential_error_count = 3 in fcmpushclient.py) in the same breath as the acks — so the same three messages came back and killed it again on the next connect. The listener was down for about a day and a half. Roughly twenty Ring app notifications produced zero Home Assistant events, while history polling carried on updating normally, which makes it look like a Home Assistant problem rather than a push problem.

Two things that may save someone else time:

1. A stuck backlog is distinguishable from a live event by the FCM message id (0:<epoch-ms><digits>%...). Hours old means replay, not a fresh notification. The library raises before it can log the payload, so firebase_messaging: debug and ring_doorbell: debug are needed to see the ids at all.

2. Clearing the backlog does not by itself restore delivery. Deleting listen_token from the config entry forces a fresh FCM registration and orphans the poisoned messages, which stops the crash loop — but Ring binds push to the device record, keyed on the hardware_id/device_id the integration registered with. A new token against the old device record is accepted and then silently ignored: no crash, no events, nothing in the log at default level. Only the integration's Reconfigure flow mints a new hardware_id (Reauth deliberately reuses the old one), followed by a restart.

That second point is the reason the crash loop and the loss of delivery need separate fixes today. This PR removes the first one, which is the one that matters: it would have turned a day and a half of silence into a handful of ignored notifications.