aanogueira opened a new pull request, #14143: URL: https://github.com/apache/apisix/pull/14143
## Problem `schema_def.lua` declares non-zero defaults for `checks.active.healthy`/`checks.active.unhealthy.interval` (minimum 1, documented as always on), but the admin schema validation only fills a sub-object's defaults when that sub-object is present in the submitted config. An entirely omitted `healthy` or `unhealthy` block never reaches that fill-in code, so those documented defaults are never written to etcd. `resty.healthcheck.new()` then fills the gap from its own defaults table, where the same fields default to `interval = 0`, which means disabled. Omitting the whole block silently disables that active check direction: `healthy.interval=0` stops re-probing currently healthy targets for failure, `unhealthy.interval=0` stops re-probing currently unhealthy targets for recovery. This contradicts the documented and schema-enforced default of always on. ## Changes `apisix/healthcheck_manager.lua`: backfills APISIX's own active check defaults in `create_checker`, the single place `up_conf.checks` reaches `resty.healthcheck.new()`, without mutating `up_conf.checks` itself, since it may be shared or cached and read elsewhere (for example by the admin API). ## Validation `t/node/healthcheck-passive-healthy-omitted.t` reproduces the bug end to end: - TEST 1 to 3 confirm the same gap on the passive side (schema check does not synthesize a missing `passive.healthy`, and `resty.healthcheck`'s own default of `successes = 5` fills in silently instead of "disabled"). - TEST 4 confirms the active side: omitting `checks.active.healthy` leaves the running checker with `interval = 0` (timer not actually running), despite the schema documenting and enforcing a minimum of 1. - TEST 5 confirms the fix: routing the same input through `backfill_active_health_check_defaults` before `healthcheck.new()` restores `interval = 1` with the timer actually running, and leaves the original `up_conf.checks` table untouched. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
