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
Incident (2026-08-29, field report ~10 min after v2.3.0 stable published)
A site on v1.15.0 installed the Easee cloud driver the day before, ending up with is_site_meter: true on both pixii and easee-cloud. v1.15.0 ran fine — SiteMeterDriver() returns the first match, so the duplicate was silently ignored in favor of pixii.
#844 (in v2.0.0) turned the duplicate into a hard Validate() error. On update to v2.3.0 the box crash-looped at boot:
level=ERROR msg="load config" err="exactly one driver may set is_site_meter: true (found 2)"
os.Exit(1) fires before the boot-phase HTTP listener binds, so the box was "stone dead" from the operator's view — host pinged, no UI, no Settings to fix the config with. Recovery required SSH and hand-editing YAML. The updater health-gate correctly judged the deploy failed, but a later restart came up on the new image anyway (separate issue).
#844's intent was right: a silently ignored second site meter means the operator thinks meter B is the site boundary while dispatch trusts meter A. But a boot-time hard failure converts a working site into an unreachable one, on the exact class of box (validated config written by an older version) that can least afford it. Validation strictness must depend on the door:
Write path (Settings save, bootstrap POST /api/config): keep the hard error. The operator is present, sees the message, and can fix it before anything persists.
Load path (boot, hot reload): tolerate and demote — keep the first declaredis_site_meter (identical to the pre-fix(config): reject >3 fuse phases and duplicate site meters #844 behavior every older box already ran with), clear the flag on the rest, log ERROR, and surface a load warning so the ambiguity is visible instead of silent.
This keeps #844's visibility win, removes the brick.
Not in scope
Zero site meters still fails at load — that severity predates 1.0, no working box ever booted without one.
The update/rollback recovery gap (restart re-applied the rolled-back version) is filed separately.
Incident (2026-08-29, field report ~10 min after v2.3.0 stable published)
A site on v1.15.0 installed the Easee cloud driver the day before, ending up with
is_site_meter: trueon bothpixiiandeasee-cloud. v1.15.0 ran fine —SiteMeterDriver()returns the first match, so the duplicate was silently ignored in favor ofpixii.#844 (in v2.0.0) turned the duplicate into a hard
Validate()error. On update to v2.3.0 the box crash-looped at boot:os.Exit(1)fires before the boot-phase HTTP listener binds, so the box was "stone dead" from the operator's view — host pinged, no UI, no Settings to fix the config with. Recovery required SSH and hand-editing YAML. The updater health-gate correctly judged the deploy failed, but a later restart came up on the new image anyway (separate issue).Why #844's severity is wrong at boot
#844's intent was right: a silently ignored second site meter means the operator thinks meter B is the site boundary while dispatch trusts meter A. But a boot-time hard failure converts a working site into an unreachable one, on the exact class of box (validated config written by an older version) that can least afford it. Validation strictness must depend on the door:
is_site_meter(identical to the pre-fix(config): reject >3 fuse phases and duplicate site meters #844 behavior every older box already ran with), clear the flag on the rest, log ERROR, and surface a load warning so the ambiguity is visible instead of silent.This keeps #844's visibility win, removes the brick.
Not in scope
🤖 Generated with Claude Code