fix(ptica): загрузка ЦП больше не пишется в категориальную колонку (#2464-B) #2882

Merged

lekss361 merged 1 commit from fix/2464-eesk-load-index into main

2026-08-15 19:27:51 +00:00

bot-backend commented

2026-08-14 05:59:03 +00:00

Collaborator

Что

Лоадер ЕЭСК писал степень загрузки из колонки E листа так:

load_index = COALESCE(load_index, CAST(:load_pct AS text))

load_index — категориальная колонка: 'open'|'limited'|'closed'|NULL
(data/sql/180_connection_capacity.sql:35), её заполняет
rosseti_wfs_loader._map_load_index ровно этими тремя значениями.

Что ломается от числа в этой колонке

Обе стороны сразу:

Где	Что происходит
фронт, `classifyLoadIndex`	всё вне перечисления → `null` → точка на карте «неизвестно»
`power_summary.by_load_index`	это словарь по значению → рядом с `open/limited/closed` появился бы бакет с именем `"41.0"` и счётчиком 1

То есть значение не просто не помогает — оно деградирует уже работающий показатель.

Почему сегодня не стреляет

load_index заполнен у всех строк, COALESCE не проваливается:

всего строк   3416
open           2741
limited         346
closed          329
NULL              0

(замер верификации 13.08, независимо переснят скептиком). Первая же строка с пустым
индексом положила бы туда число — это «не сработало сегодня», а не «работает правильно».

Как

Из UPDATE убран блок load_index = COALESCE(...).
Колонка E больше не читается: места под процент в power_supply_centers нет —
load_index категориальный, current_load_mva в мегавольт-амперах. Записать
процент значило бы либо испортить категориальное поле, либо ошибиться единицами.
_pct_share_to_percent оставлен с тестами, но в докстроке теперь прямо написано, что
продакшен-вызывающих у него нет и при каком условии он снова понадобится (числовая
колонка под процент). Иначе это был бы ровно тот «код есть, эффекта нет», который
выглядит работающим.

Проверка

Старый тест фиксировал ровно отменяемое поведение:

assert first["load_pct"] == 41.0  # доля 0.41 → 41.0%

Заменён на проверку, что ни SQL, ни параметры загрузку не несут. Пришлось сравнивать
исполняемый текст, а не прозу: слово load_index осталось в поясняющем комментарии
внутри SQL, и наивная проверка на подстроку падала на собственном объяснении — комментарии
из строки вырезаются перед сравнением.

Двусторонность против лоадера из main:

1 failed, 10 passed
    FAILED test_load_ps_35_220_does_not_write_load_percent
после правки: 11 passed

pytest tests/test_eesk_reserve_loader.py — 11 passed
ruff check — clean

Что осталось

Процент загрузки ЦП сейчас нигде не хранится. Если он нужен продукту — заводить под
него числовую колонку (load_pct NUMERIC) отдельной миграцией; парсер для листа уже есть
и покрыт тестами. Если не нужен — удалить _pct_share_to_percent вместе с тестом, а не
держать молча.

Refs #2464

## Что Лоадер ЕЭСК писал степень загрузки из колонки E листа так: ```sql load_index = COALESCE(load_index, CAST(:load_pct AS text)) ``` `load_index` — **категориальная** колонка: `'open'|'limited'|'closed'|NULL` (`data/sql/180_connection_capacity.sql:35`), её заполняет `rosseti_wfs_loader._map_load_index` ровно этими тремя значениями. ## Что ломается от числа в этой колонке Обе стороны сразу: | Где | Что происходит | |---|---| | фронт, `classifyLoadIndex` | всё вне перечисления → `null` → точка на карте «неизвестно» | | `power_summary.by_load_index` | это словарь **по значению** → рядом с `open/limited/closed` появился бы бакет с именем `"41.0"` и счётчиком 1 | То есть значение не просто не помогает — оно деградирует уже работающий показатель. ## Почему сегодня не стреляет `load_index` заполнен у **всех** строк, `COALESCE` не проваливается: ``` всего строк 3416 open 2741 limited 346 closed 329 NULL 0 ``` (замер верификации 13.08, независимо переснят скептиком). Первая же строка с пустым индексом положила бы туда число — это «не сработало сегодня», а не «работает правильно». ## Как - Из UPDATE убран блок `load_index = COALESCE(...)`. - Колонка E больше не читается: места под процент в `power_supply_centers` нет — `load_index` категориальный, `current_load_mva` в **мегавольт-амперах**. Записать процент значило бы либо испортить категориальное поле, либо ошибиться единицами. - `_pct_share_to_percent` оставлен с тестами, но в докстроке теперь прямо написано, что **продакшен-вызывающих у него нет** и при каком условии он снова понадобится (числовая колонка под процент). Иначе это был бы ровно тот «код есть, эффекта нет», который выглядит работающим. ## Проверка Старый тест фиксировал **ровно отменяемое поведение**: ```python assert first["load_pct"] == 41.0 # доля 0.41 → 41.0% ``` Заменён на проверку, что ни SQL, ни параметры загрузку не несут. Пришлось сравнивать **исполняемый текст**, а не прозу: слово `load_index` осталось в поясняющем комментарии внутри SQL, и наивная проверка на подстроку падала на собственном объяснении — комментарии из строки вырезаются перед сравнением. Двусторонность против лоадера из main: ``` 1 failed, 10 passed FAILED test_load_ps_35_220_does_not_write_load_percent после правки: 11 passed ``` - [x] `pytest tests/test_eesk_reserve_loader.py` — 11 passed - [x] `ruff check` — clean ## Что осталось Процент загрузки ЦП сейчас **нигде не хранится**. Если он нужен продукту — заводить под него числовую колонку (`load_pct NUMERIC`) отдельной миграцией; парсер для листа уже есть и покрыт тестами. Если не нужен — удалить `_pct_share_to_percent` вместе с тестом, а не держать молча. Refs #2464

bot-backend added 1 commit 2026-08-14 05:59:04 +00:00

fix(ptica): загрузка ЦП больше не пишется в категориальную колонку

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI Trade-In / changes (pull_request) Successful in 7s

Details

CI / changes (pull_request) Successful in 9s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Successful in 2m19s

Details

CI / backend-tests (pull_request) Successful in 16m23s

Details

fe019f26ee

Лоадер ЕЭСК писал степень загрузки из колонки E как
`load_index = COALESCE(load_index, CAST(:load_pct AS text))`.
load_index — категориальная: 'open'|'limited'|'closed'|NULL
(data/sql/180_connection_capacity.sql:35), её заполняет
rosseti_wfs_loader._map_load_index.

Число строкой в этой колонке ломает обе стороны: фронтовый classifyLoadIndex
отбрасывает всё вне перечисления в null («неизвестно»), а
power_summary.by_load_index — словарь по значению, то есть получил бы бакет
с именем вида "41.0" рядом с open/limited/closed.

Сегодня не стреляло только потому, что load_index заполнен у всех строк
(open 2741 / limited 346 / closed 329, NULL 0 — замер верификации 13.08,
подтверждён вторым прогоном скептика), и COALESCE не проваливался. Первая же
строка с пустым индексом положила бы туда число.

Колонку E больше не читаем: места под процент в power_supply_centers нет —
load_index категориальный, current_load_mva в мегавольт-амперах.

_pct_share_to_percent оставлен с тестами, но в докстроке теперь прямо
написано, что продакшен-вызывающих у него НЕТ и при каких условиях он снова
понадобится — чтобы «код есть, эффекта нет» не выглядел работающим.

Старый тест фиксировал ровно отменяемое поведение (`first["load_pct"] == 41.0`)
— заменён на проверку, что ни SQL, ни параметры загрузку не несут. Проверять
пришлось исполняемый текст, а не прозу: слово load_index осталось в поясняющем
комментарии, и наивная проверка на подстроку падала на своём же объяснении.

Тесты двусторонние: против лоадера из main падает ровно новый.

Хунк форматирования — не мой: pre-commit ruff v0.7.4 против 0.15.12 (#2864).

Refs #2464