Description
Is your feature request related to a problem? Please describe.
Currently, Diun lacks a retry mechanism for notifications. In environments with unstable networks, notifications (such as Webhook/Bark or Mail) often fail due to transient issues like i/o timeout or context deadline exceeded.
In my case, Diun successfully detects image updates, but the notification fails, and no further attempts are made until the next cron cycle. This leads to missed alerts unless I manually restart the container.
Describe the solution you'd like
It would be highly beneficial to have a built-in retry logic for notification providers. Key features could include:
Retry count: A configurable number of retries (e.g., max_retries: 3).
Retry interval: An optional delay between attempts (e.g., retry_interval: 10s).
Exponential backoff: Ideally, a simple backoff strategy to prevent hammering the notification server during a downtime.
Describe alternatives you've considered
I am currently using an external shell script to monitor Docker logs and restart the Diun container whenever a notification failed error is detected. This forces a re-scan due to runOnStartup: true, but it's a workaround that causes unnecessary container restarts and duplicate log entries.
Additional context
Example logs showing the failure:
Plaintext
ERR Mail notification failed error="dial tcp: lookup smtp.qiye.aliyun.com: i/o timeout"
ERR Webhook notification failed error="Post "https://api.day.app/...\": context deadl
Description
Is your feature request related to a problem? Please describe.
Currently, Diun lacks a retry mechanism for notifications. In environments with unstable networks, notifications (such as Webhook/Bark or Mail) often fail due to transient issues like i/o timeout or context deadline exceeded.
In my case, Diun successfully detects image updates, but the notification fails, and no further attempts are made until the next cron cycle. This leads to missed alerts unless I manually restart the container.
Describe the solution you'd like
It would be highly beneficial to have a built-in retry logic for notification providers. Key features could include:
Retry count: A configurable number of retries (e.g., max_retries: 3).
Retry interval: An optional delay between attempts (e.g., retry_interval: 10s).
Exponential backoff: Ideally, a simple backoff strategy to prevent hammering the notification server during a downtime.
Describe alternatives you've considered
I am currently using an external shell script to monitor Docker logs and restart the Diun container whenever a notification failed error is detected. This forces a re-scan due to runOnStartup: true, but it's a workaround that causes unnecessary container restarts and duplicate log entries.
Additional context
Example logs showing the failure:
Plaintext
ERR Mail notification failed error="dial tcp: lookup smtp.qiye.aliyun.com: i/o timeout"
ERR Webhook notification failed error="Post "https://api.day.app/...\": context deadl