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

- **Секция:** ядро
- **Зачем:** Тренировка с меткой в неизвестном формате пропадает целиком — а её id и содержимое разобраны
- **Теги:** goal:parsing-and-storage, question

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

## Что известно

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

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

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

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