Retry ID

A service call now cancels a previous running call with the same retry ID. A new retry_id parameter can be used to set the retry ID explicitly but it should be rarely used, if at all. The default value of retry_id is the entity ID of the inner service call. An example of the cancellation scenario might be when turning off a light while the turn on retry loop of the same light is still running due to failures or light's transition time. The turn on retry loop will be getting canceled by the turn off call since both share the same retry_id by default (the entity ID). Although this is a breaking change it's unlikely to break an existing use case. Additional information about this new functionality, including how to disable it, can be found here.

v2.9.3 adds the following logic: retry loops created by the same service call (retry.call or retry.actions), for example for multiple entities, are not canceling each other even when they have identical retry_id. This scenario can happen only when setting retry_id explicitly.

Full Changelog: v2.8.0...v2.9.3