mirror of
https://github.com/alexbelgium/hassio-addons.git
synced 2026-08-24 05:43:32 +02:00
* fix: wait for the Supervisor API before running startup scripts 48 add-ons build their nginx ingress config out of bashio::addon.ip_address and bashio::addon.ingress_port. Both come from one GET /addons/self/info, and when that is answered before the Supervisor is ready bashio prints nothing. Nine add-ons paste the result straight into a sed and end up writing "listen : default_server;", which nginx rejects with `invalid port in ":"`; the other 39 assign first and abort under set -e, leaving %%port%% placeholders. Either way ingress is dead for that boot. ha_entrypoint.sh now polls /addons/self/info once before the cont-init loop and waits until it reports this add-on's ip_address (and, for ingress add-ons, a non-zero ingress_port). Bounded at 30s via HA_SUPERVISOR_WAIT, never fatal, and skipped entirely without SUPERVISOR_TOKEN or curl. When the Supervisor is already up -- the normal case -- it costs one request. qBittorrent is bumped so the change is actually built and reaches the add-on with the open report; the other add-ons pick it up on their next rebuild. Refs #2949, #2962 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: harden the Supervisor wait after bot review - HA_SUPERVISOR_WAIT=08 was accepted by test -gt but read as octal by arithmetic expansion, leaving deadline empty; the comparison then errored every iteration and the loop never exited, hanging start-up. Digits-only validation plus base-10 forcing. - A request started near the deadline could run --max-time past it. The per-request timeout is now capped to the time remaining, and the retry sleep is skipped once the budget is gone, so the ceiling is exact. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * refactor: probe the Supervisor through bashio instead of curl + sed The wait reimplemented what the 48 consumers already do: it called /addons/self/info with curl and picked the fields out with sed. That parallel implementation was where one of the review findings landed, and it left a residual race -- proving the API answered a moment ago says nothing about the bashio call that runs next. Probing through bashio removes both. bashio caches a successful /addons/self/info under ${CACHE_DIR:-/tmp/.bashio}, so once the probe returns, every bashio::addon.* call in every cont-init script reads that file rather than asking the Supervisor again. Verified: one bashio::addon.ip_address call writes a 26 KB addons.self.info.cache. One call also settles all the fields, so the separate ingress/ingress_port branch was redundant and is gone: a populated ip_address means the whole object is cached. 36 -> 31 code lines. Two consequences handled: bashio's own curl carries no --max-time (api.sh:41), so each attempt is bounded with timeout; and bashio-standalone.sh answers these calls from environment variables without ever contacting the Supervisor, so BASHIO_LIB_FULL gates the probe to images carrying the real library. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>