Обновить

redb 3.6.0: багрепорт, который оказался в шести провайдерах сразу — плюс AS2/EDI и общий порт

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели3.5K
Всего голосов 1: ↑1 и ↓0+3
Комментарии2

Комментарии 2

интересный баг. как быстро выловили проблему? покрывали код тестами перед релизом?

Оба выловили не тестами, а на живом приложении: строили на этом же стеке своё — телеграм-бот через redb.Route.Telegram как фронт, а за ним LLM-часть, работающая с оперативными данными. Там и вылезло.

Тесты были — и в этом самое интересное. Они не покрыли эти кейсы, потому что писал их я же и ровно под тот способ использования, который держал в голове. У API несколько равноправных путей, а покрыт оказался мой.

Пример прямо из этого релиза: URI эндпоинтов я всегда писал строкой, а не fluent-строителем. Поэтому расхождение кодека строителя с парсером — значения с пробелами не переживали круговой обход — у меня физически не могло воспроизвестись: этой ветки в моём коде не было. Тест «маршрут работает» проходил, потому что проверял мой путь.

С деревьями последствия серьёзнее. WhereLeaves() замещал корневой CTE вместо того, чтобы быть предикатом поверх него, то есть запрос молча означал «свежайший лист схемы во всей базе». Ошибки нет, ответ правдоподобный — просто не про того. На одном собеседнике это невидимо в принципе; в боте со вторым пользователем видно сразу — человеку приезжает чужая история.

Сейчас оба пути закрыты тестами, фикс дерева ушёл во все шесть провайдерных комбинаций и в нативное расширение SQLite.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации