rate_add_io_slots: 'already underway' check rounds to the 30-min block, can treat a not-yet-started dispatch as trusted #4808

Activity

1. springfall2008 commented on Aug 28, 2026

   

   springfall2008

   on Aug 28, 2026

   Owner

   More actions

   Automated first-pass triage — a maintainer will review before any action is taken.

   Classification: bug
   Priority: priority_low (see reasoning below)

   What I checked

   This issue describes code that is not on main — it exists only in the still-open PR #4483 (fix/iog-limit-future-slots-by-ev-soc, authored by @chalfontchubby, same as this issue). I confirmed this by resetting the local clone to current main (v8.53.5-10-gc2135caa) and reading rate_add_io_slots() in apps/predbat/octopus.py directly — there is no current_block, needed, or per-slot "trust it, already underway" logic there at all yet. I then pulled PR #4483's diff to check the report against the code it actually describes.

   Verified root cause

   The report is accurate. Two things combine:

   1. Existing code on main (unrelated to fix(octopus): don't rely on future IOG dispatch slots the car no longer needs #4483, so this line number is stable): apps/predbat/octopus.py:3061 floors the dispatch's raw start to the 30-minute settlement boundary — start_minutes = (start_minutes // plan_interval_minutes) * plan_interval_minutes — before any "already underway" decision is made. The true per-minute dispatch start returned by decode_octopus_slot(..., raw=True) (minute-precision, via minutes_to_time()) is discarded at that point and never retained.
   2. PR fix(octopus): don't rely on future IOG dispatch slots the car no longer needs #4483's new check then compares two values derived from that same floored boundary — slot_start <= current_block, where current_block = (self.minutes_now // 30) * 30 — so it can't distinguish a dispatch that started exactly at the top of the block from one that starts anywhere up to 29 minutes into it.

   This isn't just theoretical: self.minutes_now (predbat.py:652) advances in PREDICT_STEP (5-minute) increments, which is finer than the 30-minute settlement block — so a real Predbat cycle at, say, 10:05 or 10:10 will indeed see current_block == 600 and trust a 10:20 dispatch as already-underway, exactly as described.

   The proposed fix (capture the raw start separately, compare it to self.minutes_now directly rather than current_block) is the right shape for a fix.

   Other checks

   • Duplicates: none. rate_add_io_slots: zero-kWh exemption can't distinguish malformed SMART input from a genuine zero-kWh event #4807 and rate_add_io_slots: multi-car ordering can let one car's rejection clobber another car's accepted slot #4809 are sibling issues from the same author/review thread, but each scopes a distinct bug (zero-kWh SMART exemption vs. this rounding issue vs. multi-car ordering) — not duplicates of each other.
   • Test suite: ran rate_add_io_slots via tools/triage_test.sh — 17/17 pass on main, but none exercise the needed/current_block logic since that code isn't merged yet. This only confirms main's pre-fix(octopus): don't rely on future IOG dispatch slots the car no longer needs #4483 behaviour is unaffected; it doesn't validate the fix.
   • Since fix(octopus): don't rely on future IOG dispatch slots the car no longer needs #4483 is unmerged, there's no user-facing impact today — hence priority_low despite the root cause being confirmed. Impact becomes real once fix(octopus): don't rely on future IOG dispatch slots the car no longer needs #4483 lands, at which point this should be picked up as a stacked follow-up as proposed.
2. springfall2008

   added

   bugSomething isn't workingSomething isn't working

   priority_low

   Octopus

   BOT_TRIAGEDHas been through the triage botHas been through the triage bot

   on Aug 28, 2026
3. springfall2008

   added a commit that references this issue on Sep 7, 2026

   fix(octopus): scope the zero-kWh dispatch exemption to genuinely pars…

   ...

   8faa403