Сохранёнки программиста

Go 1.27 сохраняет HTTP-соединение после закрытия непрочитанного ответа Клиенту нужен только статус ответа, поэтому он вызывает resp.Body.Close() и идёт дальше. В Go до версии 1.27 непрочитанное тело HTTP/1-ответа мешало повторно использовать соединение. Следующий запрос мог снова тратить время на TCP и TLS. В Go 1.27 транспорт дочитывает остаток в фоне: на это выделено до 50 мс и 256 КБ. Если тело удалось прочитать до конца, соединение можно вернуть в пул. При заголовке Connection: close эта работа пропускается. В примере команды Go сто последовательных HTTP/1-запросов заняли около 150 мс вместо 710 мс на прежней версии. Проверьте код, где тело ответа закрывается сразу после получения статуса или чтения JSON. На Go 1.27 обычного Close() достаточно, чтобы транспорт сам попробовал сохранить соединение.

SQL-запросы и ход расследования можно хранить рядом с кодом Нашли причину сбоя, отправили вывод в чат, закрыли вкладки. Через месяц похожая проблема возникает снова, и запросы приходится собирать заново. В Supabase появились Explorer и Notebooks: в одном документе можно сохранить запросы к базе и логам, графики и заметки о проверках. Файл хранится в папке supabase, попадает в Git и проходит обычное ревью. При повторном запуске запросы получают актуальные данные. Так удобно оформлять проверки после деплоя: какие ошибки появились, какие запросы замедлились, что изменилось в нагрузке. Explorer пока доступен в режиме предварительного просмотра. Начните с одного повторяющегося расследования и сохраните шаги, по которым коллега сможет его воспроизвести.

WAF может проверить ответ сервера перед отправкой клиенту Запрос пытается открыть служебную страницу без авторизации. Приложение возвращает HTML административной панели. Проверка ответа помогает увидеть, что сервер действительно отдал закрытое содержимое. В Cloudflare WAF добавили сопоставление запроса с ответом. Правило может учитывать путь, состояние авторизации, код ответа и другие доступные признаки. При совпадении WAF подменяет ответ страницей блокировки до отправки клиенту. Начать можно с узкого сценария: проверить обращения к административным адресам и посмотреть, какие ответы получает неавторизованный посетитель. Сначала соберите события в журнал, затем настройте блокировку. Пользовательские правила по содержимому тела ответа пока недоступны. Блокировка ответа также не отменяет действия, которые приложение уже успело выполнить на сервере.

Два распаковщика могут увидеть разные файлы в одном tar-архиве Сервис проверяет архив и видит безопасный файл. Установщик открывает тот же архив — и находит дополнительный файл с другим содержимым. Такое возможно, когда программы по-разному трактуют записи tar. В разборе tar-codec есть примеры расхождений, из-за которых проверка и последующая распаковка получают разные наборы файлов. Команда Astral столкнулась с этим при работе над uv и написала более строгий парсер. Начиная с uv 0.13 он используется для обработки исходных пакетов Python. Если ваш сервис принимает архивы, проверьте всю цепочку: чем проверяете содержимое, чем распаковываете и какие варианты формата разрешаете. Добавьте в тесты архивы с повторяющимися именами и неоднозначными заголовками. Проверяющая и использующая файл части системы должны одинаково понимать его содержимое.

GitHub автоматизировал пересмотр доступов внешних участников Подрядчик закончил работу, тестовый проект закрыли, а права на репозиторий остались. Когда таких проектов десятки, ручную проверку легко отложить. В GitHub для общей организации создали приложение Evergreen. Раз в квартал оно открывает задачу со списком внешних участников. Владелец подтверждает тех, кому доступ ещё нужен. По истечении срока неподтверждённые права отзываются. Отдельный процесс ищет репозитории без недавней активности людей: сначала предупреждает владельца, затем архивирует проект. Решения и изменения сохраняются в задачах и JSON-файлах управляющего репозитория. Для своей команды можно начать с одного действия: назначить владельца каждому репозиторию и дату следующего пересмотра доступов. Затем автоматизировать напоминания и журнал решений.

Общий ключ шардирования помогает оставить JOIN внутри одной базы Таблицы клиентов и заказов распределили по разным серверам: клиентов — по id, заказы — по собственному id. Теперь запросу «клиент и его заказы» приходится собирать данные с нескольких шардов. В разборе групп шардирования показан другой подход: размещать заказы по customer_id, используя то же правило распределения, что и для клиентов. Связанные строки окажутся на одном шарде, где можно выполнить JOIN и транзакцию локально. Перед выбором ключа выпишите основные запросы приложения. Какие таблицы они соединяют? Какие строки меняются вместе? Какой идентификатор известен в начале запроса? Эти ответы помогут выбрать размещение данных. Особенно полезно проверить запросы, в которых будущего ключа шардирования вообще нет: для них может потребоваться обращение к нескольким шардам.

git add --resolved добавляет исправленные конфликты отдельно от остальных правок Во время слияния исправили конфликт в одном файле. В другом осталась локальная правка, которую пока рано включать в коммит. В Git 2.56 появилась команда для этого случая: git add --resolved git status --short Она рассматривает только пути с неразрешёнными конфликтами в индексе. Перед добавлением проверяет обычные файлы на оставшиеся маркеры конфликта. Если находит их, сообщает о проблеме и оставляет индекс без изменений. Можно передать путь, чтобы ограничить проверку отдельными файлами. После команды посмотрите git status и подготовленный diff: маркеры будут проверены, а правильность объединённого кода нужно оценить отдельно.

Каскадное удаление может поставить запись в базу в очередь Удаляете организацию одной командой. Через ON DELETE CASCADE PostgreSQL удаляет её пользователей, заказы и связанные записи дальше по цепочке. Вся работа выполняется в одной транзакции. В разборе PlanetScale показан сценарий: долгое удаление удерживает блокировки таблиц, миграция ждёт эксклюзивную блокировку, а новые запросы выстраиваются за миграцией. Запись в приложение начинает зависать. Перед массовым удалением проверьте объём связанных данных и индексы на столбцах внешних ключей. Для крупных операций предусмотрите удаление ограниченными порциями с короткими транзакциями. У миграций настройте lock_timeout, чтобы они быстро завершались ошибкой при занятой таблице и могли быть повторены позже.

GitHub CLI научился автоматически обновлять короткоживущие токены GitHub CLI получил режим авторизации с токенами, которые истекают через несколько часов. CLI сам обновляет их с помощью отдельного обновляемого токена. Режим доступен в публичной предварительной версии начиная с gh 2.103.0. Для подключения выполните gh auth login --expiring. Проверить авторизацию можно через gh auth status, настроить помощник для Git по HTTPS — через gh auth setup-git. Рекомендуется Git 2.46 или новее. Подробности работы режима есть в инструкции по авторизации. Если скрипт использует токен из CLI, запрашивайте его через gh auth token перед каждым использованием. Однажды сохранённое значение перестанет работать после истечения срока. Существующая авторизация переключается на новый режим отдельно.

Зависимые изменения можно отправить на ревью цепочкой pull request Новая функция иногда требует сначала изменить модель данных, затем API и только потом интерфейс. Работу удобно разбить на связанные pull request: каждый содержит отдельный шаг и опирается на предыдущий. В GitHub стали общедоступны цепочки pull request. Интерфейс показывает связи, поддерживает перебазирование цепочки и совместное слияние готовых частей. При перебазировании одобрения сохраняются для кода, который остался прежним. Попробуйте подход на следующей большой задаче: выделите шаги, которые ревьюер сможет понять и проверить отдельно. В описании каждого PR укажите его место в цепочке и зависимости.