Про важливість логування та тестування

Є така фраза — «Швець без чобіт». Це сьогодні в якійсь мірі про мене. А враховуючи, що я розробляю сервіс доставки, перевірки та аудиту вебхуків, ситуація виглядає вдвічі комічно. Але спочатку передісторія.

Сьогодні вийшов новий реліз Adal CLI v0.1.2, а разом з ним і деякі оновлення на стороні сервера.

Одним із цих змін стало змінення способу зберігання вебхуків всередині Adal. Для кінцевого користувача ця міграція пройшла непомітно, але для інфраструктури Adal — це значне підвищення стабільності та якості роботи.

Одним із майбутніх покращень буде обмеження зберігання body запиту. Це може бути важливо для деяких категорій користувачів, які пересилають через вебхуки дані, вміст яких є, наприклад, конфіденційним і зберігання яких третьою стороною заборонено.

Після внесення відповідних змін у код, я протестував його працездатність. Вебхуки приймаються, обробляються, прапори зберігання встановлюються, все доходить до CLI і відправляється на кінцевий destination.

Як кінцеві destinations у мене встановлено дві адреси: одна посилається на точно працюючий хост, а друга посилається на точно не працюючий. Ну, це цілком зрозуміло: щоб бачити як обробляються різні сценарії доставки вебхуків.

Але я не врахував одного: а що саме отримує кінцевий хост? А він отримував запит без вихідного body та заголовків. Замість очікуваного payload до нього доходили лише внутрішні службові дані, які не призначені для кінцевого отримувача.

Ситуація неприємна, але не критична. На щастя, помилка не зачіпала прийом і зберігання вебхуків. Запити коректно приймалися, зберігалися і проходили весь конвеєр обробки. Проблема виникала лише на етапі формування payload для доставки.

Помилка полягала в тому, що запиту, при його зберіганні, прапор типу зберігання встановлювався, але не перевірявся сервісом доставки користувачу. Сервіс, який формує payload для доставки користувачу, отримував невідомий тип зберігання і в такому випадку повертав пустий результат.

Сам баг, звісно, був неприємним. Але мені сподобалася поведінка системи в цій ситуації. Система воліла не підставляти значення за замовчуванням і не намагатися "здогадатися", що малося на увазі.

Можна було б зробити умову «якщо не знаємо тип, то вважаємо його типом за замовчуванням», але я вважав, що краще буде вважати «якщо ми не знаємо що це, то ми не обробляємо це». Тому що «вважати за замовчуванням» — це щось із blackbox, адже потім доводиться гадати «чому на цей запит отримав саме таку відповідь».

Цей випадок ще раз нагадав мені просту річ: тестувати потрібно не окремий сервіс і не окрему функцію, а весь користувацький сценарій цілком. Можна переконатися, що вебхук прийнятий. Можна переконатися, що він збережений. Можна переконатися, що він поставлений у чергу і доставлений. Але поки не подивився, що саме отримав кінцевий endpoint, перевірка не завершена. Саме тому хороші логи та спостережуваність важливі не менше, ніж сама бізнес-логіка.

Тому я створив ще один endpoint для спостереження і змінив адресу хоста, який точно працює, на адресу нового endpoint. Тепер я буду точно бачити, що саме приходить у запиті. І вкотре переконався: ніщо не знаходить баги краще, ніж використання власного продукту кожен день. Особливо коли цей продукт призначений для вирішення твоїх власних задач.