Комментарии 6
На Github есть один баг
Звучит так как буд-то это баг самого GitHub-а, но в действительности это тикет в проекте dotnet/runtime, но в статье ни слова нет ни про .Net, C# или Microsoft.
Нет слов. Я лично научился правильно сравнивать время после прочтения одной публикации от 2005-го (!!!!!!) года и верхнего комментария к ней. Стоит ли упоминать, что публикация описывает проблему с windows ce.
У нас на пароходе был случай - идём по профилю, за кормой сейсмокоса 8 км. Судно ни с того ни сего берёт круто право, штурман среагировал перешёл на ручное, но градусов 30 уже успели отвернуть. Начинаем разбираться - не поступают данные от гирокомпаса, и это не тяп-ляп, а survey-grade Robertson. Перезапустили, развернулись, продолжили работу. Позже выяснилось из техподдержки, что у него таймер проходит через 0 примерно раз в 4 года. Разработчикам в голову не приходило, что этот срок можно превысить. Но сам факт, что гирокомпас не обесточивался всё это время, достоин уважения.
Под луной код превращается в своего рода волшебство. Этот опыт, когда окружающая атмосфера влияет на работу кода, добавляет загадочности и таинственности к разработке. Полная луна, как бы, привносит свою собственную магию в программирование, создавая уникальные условия для творчества и открытий.
Самый сложный баг, который мне приходилось чинить, был вызван неправильным закрытием транзакции. Код как бы отсылал "end;" на сервер постгреса, но не дожидался ответа, и из-за некоторой специфики драйвера следующие операторы произвольно попадали внутрь той же транзакции.
И всё бы ничего, но иногда транзакция завершалась с ошибкой и роллбэчилась, и вот тогда происходил сущий кошмар.
Представьте, что вы смотрите на два последовательных успешных update-запроса к базе, которые вообще не связаны с той транзакцией, но при этом первый из запросов никак не изменил данные, а второй изменил.
Я пока этот баг искал успел прочитать код драйверав в поисках ошибки
При полной луне этот код работал иначе