Files

T

Дозакрыты находки ревью по слиянию сущностей

- Правило покрытия получило второй разряд (условный, как у точек), запрет
  вырождения формы и счёт содержательных элементов ряда: скелет из скаляров и
  ряд из null больше не затирают маршрут. Победитель внутри доставки стал
  функцией множества версий — общим помощником с точками, — а провенанс
  поднимается и при совпавшем хеше, иначе отложенная доставка возвращала витрину
  к прежнему содержимому.
- Одно поле не того типа больше не уносит сущность, а пропуски видны в учётной
  записи доставки (миграция 00008, NULL = «не измерялось»); каноническая форма
  считается один раз и вне транзакции; откат бинаря поверх новой схемы отказывает
  на старте; текст ошибки разбора не несёт значений из тела.
- Ревью кода профилем deep (девять проходов) нашло две регрессии и обе закрыты:
  безусловный второй разряд запирал законный досчёт навсегда, а выбор победителя
  был квадратичен по числу присланных версий одного ключа.

2026-08-02 16:38:18 +03:00

3.1 KiB

Raw Blame History

Сущность с id, но неразобранной меткой

Приоритет: средний

Остаток задачи «Дозакрыть находки ревью по слиянию сущностей» (архивный change dozakryt-nahodki-sushchnostej). Та задача сделала мягким чтение заголовка: поле не той формы стоит одного поля, а не сущности. Но метка исключение — разбор кладёт сущность в ts_utc/start_utc, колонки NOT NULL, и сущность с неразбираемой меткой по-прежнему пропускается целиком.

Что известно

Оракул: internal/hae/entity_test.go, случаи «метка в ином формате», «метка Unix-эпохой», «метки нет вовсе» — сущность в результат разбора не попадает, счётчик SkippedEntityNoTime растёт.
После той задачи пропуск виден в базе: у доставки есть skipped_entities, и ретеншен получает честный ответ «терять есть что». То есть событие больше не молчит — но содержимое всё ещё не хранится.
Достижимость из реального потока: замер на 118 доставках дал ноль пропусков всех трёх классов. Дрейф формата дат у HAE при этом задокументирован (docs/local-research.md), то есть вход не выдуман.

Что решить

Хранить ли сущность с разобранным id и неразобранной меткой. Цена:

Хранить с NULL-меткой — правка схемы (start_utc/ts_utc становятся NULLABLE) плюс правила чтения витрины: выборка «за период» обязана сказать, что делает с такими строками, иначе они молча исчезнут из любого ответа. Зато содержимое (маршрут!) сохраняется, а метку восстановит пересборка, когда разбор научится читать формат.
Не хранить — как сейчас. Тело живёт в архиве до ретеншена, доставку вернёт reindex. После включения ретеншена окно становится необратимым.
Хранить, подставив метку доставки — отвергается сразу: это выдуманное измерение в колонке, по которой идёт выборка.

Рекомендация — (1), но не раньше, чем появится Read API по сущностям: правило чтения без читателя проектируется вслепую.

3.1 KiB Raw Blame History

Сущность с id, но неразобранной меткой

Что известно

Что решить

3.1 KiB

Raw Blame History