Files
transcriber/openspec/changes/archive/2026-08-13-start-without-telegram-token/specs/intake/spec.md
T
av b733a84d6a telegram: сервис поднимается без бота и работает одним входом
- Клиент бота собирается один раз и достаётся отправителю и транспорту;
  разрез прошёл по «ответил ли Telegram»: ответ «такого бота нет» роняет
  старт, недоступность даёт подъём без Telegram (ADR-2026-08-13). Ожидание
  при сборке ограничено сроком — иначе молчащий Telegram вешал подъём.
- Недоставленный ответ не роняет шаг: пишется с job_id и считается метрикой,
  уровень по причине — WARN для неподнятого входа, ERROR для неназванного
  адресата. Заведены transcriber_intake_up и transcriber_undelivered_reply_count.
- Закрыта утечка токена в журнал: отказ разбора адреса рождается раньше
  обращения к клиенту, то есть мимо чистки на его границе.
2026-08-13 19:10:08 +03:00

6.4 KiB
Raw Blame History

Purpose

Приём записи и опрос готовности задачи расшифровки: что считается принятой записью, что уезжает в ответ и что происходит, когда запись не удалось прочитать. Плюс наличие входов: с каким из них сервис вправе подняться.

Приём по существу описан пока только для HTTP — того, что нормируют проверки. Про вход Telegram нормировано одно: настроен он или нет и что из этого следует для подъёма. Кто допущен к боту и как забирается присланная им запись, требованиями по-прежнему не описано — требование, написанное без проверки, это предположение, а не норма. Первая задача, которая трогает поведение приёма из Telegram, дописывает его сюда.

ADDED Requirements

Requirement: Недоступный или незаданный вход Telegram не мешает подъёму

Сервис SHALL подниматься, когда вход Telegram поднять не удалось, и MUST продолжать работу оставшимся входом: приём по HTTP, опрос готовности и конвейер расшифровки работают в полном объёме. Неподнятый вход MUST быть назван в журнале ровно одной записью уровня WARN при старте — с причиной и без значения токена.

Исключение одно, и оно проходит по тому, ответил ли Telegram. Ответ «такого бота нет» — ошибка настройки: бот по этому токену не появится ни от ожидания, ни от повтора, и старт MUST кончаться отказом. Сервис, молча потерявший бота после опечатки в токене, перестаёт отвечать своим отправителям, и узнать об этом было бы неоткуда.

Всё прочее — недоступность: сеть, DNS, авария Bot API, истёкший срок ожидания. Она MUST не влиять на подъём. Основной вход сервиса — не Telegram, и класть его целиком из-за чужой аварии нельзя: перезапуск в такую минуту оставил бы без работы и приём по HTTP, и панель, и конвейер, которому Telegram не нужен вовсе.

Ожидание при сборке MUST быть ограничено сроком. Без него недоступность неотличима от подъёма: обращение к Telegram стоит на пути старта, и молчащий собеседник останавливал бы его бессрочно — без записи, без порта и без пробы здоровья.

Требование нормирует наличие входа, а не приём из него.

Scenario: Токен не задан

  • GIVEN в настройках сервиса токен бота пуст
  • WHEN сервис запускается
  • THEN он поднимается и принимает записи по HTTP
  • AND конвейер расшифровки работает
  • AND бот не заведён, а в журнале ровно одна запись уровня WARN о том, что он не поднят и почему

Scenario: Токен задан и годен

  • GIVEN в настройках сервиса стоит токен, по которому Telegram признаёт бота
  • WHEN сервис запускается
  • THEN он поднимается и работает обоими входами

Scenario: Telegram не отвечает

  • GIVEN в настройках сервиса стоит непустой токен
  • AND Telegram недоступен либо не отвечает дольше отведённого срока
  • WHEN сервис запускается
  • THEN он поднимается и принимает записи по HTTP
  • AND бот не заведён, а в журнале запись уровня WARN с причиной
  • AND запись не несёт значения токена

Scenario: Telegram ответил, что такого бота нет

  • GIVEN в настройках сервиса стоит непустой токен
  • AND Telegram отвечает отказом на этот токен
  • WHEN сервис запускается
  • THEN старт кончается отказом
  • AND ни журнал, ни текст отказа не несут значения токена

Requirement: Поднятые входы видны наблюдателю

Сервис SHALL отдавать признак поднятости по каждому входу приёма отдельной метрикой. Признак MUST выставляться при сборке входа и MUST различать поднятый вход и неподнятый.

Требование стоит на том, что иначе потерянный вход не виден ничем: проба здоровья отвечает «сервис работает» и при неподнятом боте, а запись журнала живёт до ротации и вопрос «работает ли вход сейчас» не отвечает. Метрика — единственный канал наблюдения, который у владельца автоматизирован.

Scenario: Вход Telegram не поднят

  • GIVEN сервис поднялся без Telegram
  • WHEN наблюдатель читает метрики
  • THEN признак поднятости входа Telegram равен нулю
  • AND признак поднятости входа HTTP равен единице