Место заказов в стартовом мире #74

Open
opened 2026-08-07 20:44:29 +03:00 by ddmitry · 1 comment
Owner

Part of #69.

Вопрос

Появляются ли слепки заказов в стартовом мире, который make up заливает на пустой стенд, и что это делает с описью?

Сегодня стартовый мир — восемь модельных дней событий; опись (data/world-inventory.json) хранит паспорт мира и хеши дней, world-init заливает их при подъёме, а make check-clickhouse сверяет счёт по дням с описью (#42).

Решить: входят ли заказы в тот же артефакт, как выглядит их хеш при окне изменяемости K (слепок дня D меняется ещё K дней), и что тогда сторожит проверка на стенде.

Part of #69. ## Вопрос Появляются ли слепки заказов в стартовом мире, который `make up` заливает на пустой стенд, и что это делает с описью? Сегодня стартовый мир — восемь модельных дней событий; опись (`data/world-inventory.json`) хранит паспорт мира и хеши дней, `world-init` заливает их при подъёме, а `make check-clickhouse` сверяет счёт по дням с описью (#42). Решить: входят ли заказы в тот же артефакт, как выглядит их хеш при окне изменяемости K (слепок дня D меняется ещё K дней), и что тогда сторожит проверка на стенде.
ddmitry added the wayfinder:grilling label 2026-08-07 20:44:29 +03:00
Author
Owner

Вход из #72 — находка холодного ревью, которую там закрыть нечем.

При сдвиге отправки на день (#71) прогон дня D отправляет слепок дня D−1, поэтому
слепок последнего сыгранного дня не отправляется вовсе. На стартовом мире это день
7, и у 18 из 73 пар поздний назначенный заказ падает как раз на него (замерено
на каноническом зерне: plan.counters(seed, 8).pairs = 73, из них 18 имеют
max(pair_order_days) == 7).

Следствие: карта соответствий dds.identity_map строится из моста «событие
purchase ↔ заказ», а этих заказов в хранилище не будет — четверть пар стартового
мира в карту не попадёт. Счётчик пар при этом их считает: он смотрит только на
горизонт (plan.py, np.all(pair_order_days < days)) и про слепки не знает
ничего. Опись покраснеет не от ошибки, а по построению.

Две двери, и обе здесь:

  • стартовый мир досылает последний слепок — тогда закрытых окном дней станет два,
    и число в §6 резолюции #72 (N − 7) поедет;
  • либо счётчик пар учится спрашивать не «уложились ли назначенные дни в горизонт»,
    а «доехали ли эти заказы в отправленном слепке».

Со стороны #72 подпёрто тем, что назначенные планом заказы не опаздывают и их
события не теряются, — но заказ, у которого слепка нет вовсе, этим не спасти.

Вход из #72 — находка холодного ревью, которую там закрыть нечем. При сдвиге отправки на день (#71) прогон дня D отправляет слепок дня D−1, поэтому слепок последнего сыгранного дня не отправляется вовсе. На стартовом мире это день 7, и **у 18 из 73 пар поздний назначенный заказ падает как раз на него** (замерено на каноническом зерне: `plan.counters(seed, 8).pairs` = 73, из них 18 имеют `max(pair_order_days) == 7`). Следствие: карта соответствий `dds.identity_map` строится из моста «событие `purchase` ↔ заказ», а этих заказов в хранилище не будет — четверть пар стартового мира в карту не попадёт. Счётчик пар при этом их считает: он смотрит только на горизонт (`plan.py`, `np.all(pair_order_days < days)`) и про слепки не знает ничего. Опись покраснеет не от ошибки, а по построению. Две двери, и обе здесь: - стартовый мир досылает последний слепок — тогда закрытых окном дней станет два, и число в §6 резолюции #72 (`N − 7`) поедет; - либо счётчик пар учится спрашивать не «уложились ли назначенные дни в горизонт», а «доехали ли эти заказы в отправленном слепке». Со стороны #72 подпёрто тем, что назначенные планом заказы не опаздывают и их события не теряются, — но заказ, у которого слепка нет вовсе, этим не спасти.
Sign in to join this conversation.