av
b733a84d6a
- Клиент бота собирается один раз и достаётся отправителю и транспорту; разрез прошёл по «ответил ли Telegram»: ответ «такого бота нет» роняет старт, недоступность даёт подъём без Telegram (ADR-2026-08-13). Ожидание при сборке ограничено сроком — иначе молчащий Telegram вешал подъём. - Недоставленный ответ не роняет шаг: пишется с job_id и считается метрикой, уровень по причине — WARN для неподнятого входа, ERROR для неназванного адресата. Заведены transcriber_intake_up и transcriber_undelivered_reply_count. - Закрыта утечка токена в журнал: отказ разбора адреса рождается раньше обращения к клиенту, то есть мимо чистки на его границе.
91 lines
6.4 KiB
Markdown
91 lines
6.4 KiB
Markdown
## 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 равен единице
|