av
8f7c3a057a
- убраны клиент бота, транспорт обновлений, отправитель сообщений, сборка входа при старте, секция настроек и зависимость go-telegram-bot-api; из конвейера ушла доставка ответа отправителю — исход виден опросом готовности. Колонки адресата и значение источника остались в схеме: применённые шаги не переписываются - шаг 202608140003 запрещает пустого владельца у аудиозаписи и у файла; существующие строки он не проверяет, и это принято сознательно — искать их надо запросом до выкладки - ревью нашло два пред-существующих дефекта, оба закрыты: пустой второй ответ распознавателя стирал сохранённую расшифровку, а пустая расшифровка перестала быть заметной вместе с убранной доставкой. Попутно поднят golang.org/x/image до v0.45.0 — красный шаг vulns, воспроизводился и на чистом master
2.9 KiB
Метка убранного входа не выставляется вовсе, а не обнуляется
- Дата: 2026-08-15
- Источник: openspec/changes/archive/2026-08-15-remove-telegram-intake/design.md, раздел «Метка убранного входа не выставляется вовсе»
Решение
Признак поднятого входа остался, а метки убранного входа в метриках нет вовсе —
ни со значением единицы, ни со значением нуля. Ряд transcriber_intake_up с
меткой telegram не появляется после выкладки.
Почему
Цитата источника:
Признак поднятого входа остаётся, метка
telegramу него больше не появляется. Ноль вместо неё читается как «вход есть, но не поднялся», то есть как поломка; владелец, у которого на этот признак стоит отбор, увидел бы аварию на ровном месте.
Отвергнут очевидный подход — оставить ряд со значением нуля. Он выглядит бережнее (отбор не ломается), но говорит неправду: значение нуля у этого признака означает именно неподнятый вход, а не отсутствующий.
С единственным оставшимся входом проверяемым осталось только множество меток: значение нуля у него недостижимо, потому что страница метрик отдаётся тем же сервером, что и приём, — чтобы прочитать признак, надо дотянуться до входа, о котором он сообщает. Различать поднятый и неподнятый вход признак станет снова, когда входов у сервиса станет больше одного.
Последствия
+наблюдатель не видит вечного нуля, который читался бы как незакрытая авария.−отбор видаtranscriber_intake_up == 0по убранному входу перестаёт срабатывать молча: исчезновение ряда ловитсяabsent(), а не сравнением. Владельцу, если такой отбор был заведён, править его руками.−требование «различать поднятый и неподнятый» стало непроверяемым до возвращения второго входа, и это сказано в самом требовании прямо.