Beta 10 never goes through initialisation

[ridax67]

bess-debug-2026-08-17-115354.md
Stuck on initialisation.

[johanzander]

@claude-bot analyze

[bess-manager-claude-bot]

Root cause

Not a sensor, discovery, or config problem — the debug bundle's health check reports all 7 components OK, including price data, at export time. The system is genuinely stuck: every hourly optimization attempt (14 in a row across two full app restarts, 11:08–11:52) fails with the identical error, so no schedule is ever produced and the dashboard never leaves "initializing." The failure is a structural scaling limit in the new #450 hybrid PWL solver (shipped this beta, alongside #512's finer 0.1 kW/0.025 kWh grid resolution): detect_tie_windows can merge near-tie periods into an arbitrarily long window with no cap, but the exact solver that re-certifies such a window (run_pwl_window_backward_induction) can only afford to do so for roughly 8 periods before its own accuracy budget is exhausted by design. When that budget is exceeded, the project's fail-loud discipline correctly refuses to splice an uncertified result — but the caller has no partial-success path, so it discards the entire schedule (including all the periods that solved fine) and returns None. With no schedule, the health-check retry logic re-runs the same optimization against the same effectively-unchanged inputs and hits the same wall every time.

Evidence

• core/bess/pwl_window_dp.py:591-599 — the raising check:

  preimage_points = xs_next.size * discharge_energy.size
  if preimage_points > PWL_MAX_PREIMAGE_SEED_POINTS:
      raise PWLWindowUnderRefinedError(
          f"PWL window t={t}: exact discharge-preimage seeding would need "
          f"{preimage_points} points > PWL_MAX_PREIMAGE_SEED_POINTS="
          f"{PWL_MAX_PREIMAGE_SEED_POINTS}. ..."
      )

  This fired 14 times with the bit-identical point count 1,064,944, confirming the inputs (today's prices, cached consumption forecast, static 100%-SOC idle battery) were unchanged between attempts.
• core/bess/tie_detection.py:118-135 (detect_tie_windows) — merges any overlapping/adjacent flagged windows with no cap on merged length:

  raw_windows.sort(key=lambda w: w.start)
  merged: list[Window] = [raw_windows[0]]
  for w in raw_windows[1:]:
      last = merged[-1]
      if w.start <= last.end:
          merged[-1] = Window(start=last.start, end=max(last.end, w.end))
      ...

• core/bess/tests/synthetic/measure_tie_coverage.py:380-386 — the project's own test harness already documents the scaling limit: "the solver's breakpoint set compounds per backward step ... exhausting PWL_MAX_PREIMAGE_SEED_POINTS at a horizon of 8 periods on the bug: SOE-grid discretization noise can pick sub-optimal charging window on near-tied periods #450 fixture — a 78-period exact solve is not reachable by raising budgets."
• core/bess/exceptions.py:60-76 (PWLWindowUnderRefinedError docstring) confirms this guard "fires on none of the fixture suite's scenarios" — this is the first real-world trigger.
• core/bess/battery_system_manager.py:2163-2165 — the caller has no partial-success handling; any exception discards the whole schedule:

  except Exception as e:
      logger.error(f"Optimization failed: {e}")
      return None

• core/bess/battery_system_manager.py:3216-3238 (refresh_health_check) — explicitly retries the schedule build whenever _current_schedule is None and sensors are healthy, so the same failing optimization re-runs every cycle:

  "without it, the dashboard stays on 'initializing' until the next quarterly cron tick even though this health check now reports the system healthy."

• docs/agents/optimizer-architecture.md:297-301 — the missing safety net for this exact scenario ("splice cost-gate") is called out as "aspirational until the Phase 2 rider lands." This bundle is a live instance of the gap that rider is meant to close.
• Downstream/non-causal: core/bess/inverter_controller.py:635 raises "No strategic intents available" whenever no schedule exists — this is the log_config:127 ×25 burst in the bundle, a symptom of the same root cause, not a separate bug. The 07:00:49 Nordpool 500 error is a one-off, self-recovered transient (health check confirms price data was fine at export time) and does not explain the 11:08–11:52 failures.

Proposed fix

Bound the length of merged tie windows in detect_tie_windows (or gate the splice decision on the seed-point cost before committing to an exact re-solve) so a window that would exceed PWL_MAX_PREIMAGE_SEED_POINTS falls back to a safe, explicitly-approximate path instead of raising an uncaught exception that discards the whole schedule. This is the "splice cost-gate" already anticipated in docs/agents/optimizer-architecture.md's Phase 2 rider — implementing it closes both the scaling gap and the current all-or-nothing failure mode. A minimal complementary fix in battery_system_manager.py could also let _run_optimization degrade to the grid DP's own (non-exact but not previously-untrustworthy-in-the-splice-sense) result for pathological windows rather than returning None outright, but the cost-gate is the primary fix per the existing architecture doc.

Risks / open questions

• Whether capping window length vs. gating on point-count cost is the right primitive is an optimizer-architecture design decision (the Phase 2 rider) — this needs the maintainer's call on which approach the rider should take, not a unilateral pick during implementation.
• Not confirmed from the bundle alone: the exact shape of this user's price curve that produced a >8-period merged tie window (SE3, volatile prices around 1.5+ SEK/kWh) — worth checking whether this is likely to recur across many users with similarly volatile price areas, which would raise the urgency of the Phase 2 rider beyond this one report.
• The PWLWindowUnderRefinedError docstring explicitly says the budgets (PWL_MAX_PREIMAGE_SEED_POINTS, etc.) are "the knobs to revisit if it ever fires in practice" — raising the budget alone will not fix this, since measure_tie_coverage.py already shows the point count is fundamentally unreachable for windows this long ("raising budgets" does not help past ~8 periods).

---

Reply @claude-bot fix to implement and open a draft PR.