You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The software should differentiate between container errors and app errors.
For example, if user try to access http://ddns-updater/invalid-url - that's application-level error, it should be logged, but should not result in the container health degradation.
I think the container healthcheck should be downgraded in cases, such as lack of network connectivity (can't response to DNS requests), storage issues (can't read /write) config files, etc.
But app-level errors (such as error response from Cloudflare API) should be logged, displayed in UI, but not affect container health.
Currently (v2.6.0), when ddns-updater receives error response for API request, the container state changes to unhealthy, which makes UI unaccessible on system, where routing is done via Traefik, because Traefik doesn't route to unhealthy containers.
The text was updated successfully, but these errors were encountered:
The software should differentiate between container errors and app errors.
For example, if user try to access http://ddns-updater/invalid-url - that's application-level error, it should be logged, but should not result in the container health degradation.
I think the container healthcheck should be downgraded in cases, such as lack of network connectivity (can't response to DNS requests), storage issues (can't read /write) config files, etc.
But app-level errors (such as error response from Cloudflare API) should be logged, displayed in UI, but not affect container health.
Currently (v2.6.0), when
ddns-updater
receives error response for API request, the container state changes tounhealthy
, which makes UI unaccessible on system, where routing is done via Traefik, because Traefik doesn't route to unhealthy containers.The text was updated successfully, but these errors were encountered: