Problem
`clm_agent_check_connection()` (lib/agent.c, ~line 1482) fires
`cb_on_connection(CLM_CONN_CHECKING, ...)` immediately, then calls
`agent_http_post()` and returns whatever that call returns.
`agent_http_post`/`clm_http_async_post` (lib/http_async.c, ~line 230-300)
has several paths that return a negative errno synchronously, without
ever invoking `success_cb`/`error_cb`: `calloc` failure,
`curl_multi_init`/`curl_easy_init` failure, or the auth-header `malloc`
failing.
If one of those synchronous failures happens, neither
`health_success_cb` nor `health_error_cb` ever fires, so the last state
the UI saw is `CLM_CONN_CHECKING` -- it stays showing "checking..." until
the next scheduled probe (tui.c runs this on a 20s timer), rather than
flipping to OFFLINE right away.
Impact
Low severity: only triggered by rare local resource-exhaustion conditions
(OOM, curl init failure), not by normal network errors (those correctly
go through `health_error_cb`). Self-heals within one health-check
interval (~20s). Cosmetic/confusing in the interim, not a crash or data
issue.
Fix direction
Have `clm_agent_check_connection` fire `cb_on_connection(CLM_CONN_OFFLINE,
...)` itself when `agent_http_post` returns an error synchronously,
instead of just propagating the return code with no corresponding
callback.
Found during a manual code review pass on commit 365f3d2.
Problem
`clm_agent_check_connection()` (lib/agent.c, ~line 1482) fires
`cb_on_connection(CLM_CONN_CHECKING, ...)` immediately, then calls
`agent_http_post()` and returns whatever that call returns.
`agent_http_post`/`clm_http_async_post` (lib/http_async.c, ~line 230-300)
has several paths that return a negative errno synchronously, without
ever invoking `success_cb`/`error_cb`: `calloc` failure,
`curl_multi_init`/`curl_easy_init` failure, or the auth-header `malloc`
failing.
If one of those synchronous failures happens, neither
`health_success_cb` nor `health_error_cb` ever fires, so the last state
the UI saw is `CLM_CONN_CHECKING` -- it stays showing "checking..." until
the next scheduled probe (tui.c runs this on a 20s timer), rather than
flipping to OFFLINE right away.
Impact
Low severity: only triggered by rare local resource-exhaustion conditions
(OOM, curl init failure), not by normal network errors (those correctly
go through `health_error_cb`). Self-heals within one health-check
interval (~20s). Cosmetic/confusing in the interim, not a crash or data
issue.
Fix direction
Have `clm_agent_check_connection` fire `cb_on_connection(CLM_CONN_OFFLINE,
...)` itself when `agent_http_post` returns an error synchronously,
instead of just propagating the return code with no corresponding
callback.
Found during a manual code review pass on commit 365f3d2.