#обработка_ошибок — Public Fediverse posts

Почему Idempotency‑Key не спасает от двойного списания и как это исправить

Клиент отправил платёж, не дождался ответа и повторил запрос. На сервере предусмотрен Idempotency-Key , тесты проходят, но деньги всё равно списываются дважды. Проблема возникает, когда второй запрос приходит до завершения первого: оба обработчика успевают проверить ключ и запустить оплату. Разберём, как закрыть эту гонку с помощью PostgreSQL, что делать при падении процесса и почему даже правильно реализованная идемпотентность внутри сервиса не всегда спасает от повторного списания. Разобрать решение

https://habr.com/ru/companies/otus/articles/1095234/

#postgresql #транзакции #обработка_ошибок #отказоустойчивость #race_condition #идемпотентность #конкурентные_запросы #двойное_списание #idempotencykey #платежный_api

[recovery mode] Где мне пригодился OpenClaw, а где обычный код оказался лучше. 3 истории из практики

Последние несколько месяцев я довольно плотно занимаюсь агентом на OpenClaw и постепенно подключаю его к рабочим системам, добавляю инструменты, пробую автоматизировать разные процессы. Иногда все получается довольно быстро, а иногда приходится возвращаться к тому, что уже давно работало и разбираться почему оно вдруг начало ломаться. За это время накопилось несколько историй, которые решил собрать в одной статье. В основном это внутренние рабочие задачи, без каких-то необычных архитектурных решений, но мне самому интересно наблюдать, как постепенно развивается агент, что ему можно поручить, а где лучше вообще не привлекать LLM и оставить обычный код. Расскажу про три вещи, которыми занимался - разбор зависшего обработчика лидов, выгрузку задач из 1С прямо через телегу и эксперимент с отдельным агентом для отдела продаж.

https://habr.com/ru/articles/1093976/

#1с #автоматизация #python #mcp #обработка_ошибок #интеграции #telegram #llm #aiагенты #openclaw

Как проектировать обработку ошибок и алертинг в ESB‑решениях

Практический взгляд на то, как можно строить надёжную обработку ошибок и оповещения в интеграционных решениях. Классификация ошибок, повторные попытки, очереди, защита от дублей, агрегация алертов и метрики для мониторинга — с примерами и рекомендациями для реальных проектов.

https://habr.com/ru/articles/1091164/

#интеграция #мониторинг #оповещение #обработка_ошибок #esb #шина_данных #интеграция_систем #оповещение_об_ошибках #наблюдаемость #шина_данных_предприятия

Ежедневный ряд подписчиков в MAX: публичный эндпоинт, четыре грабли и почему not_found — не измерение

У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru. Ниже — как устроен сбор и четыре места, где мы ошиблись. Самая дорогая ошибка стоила трёх ночей молчащего ряда при зелёном логе и exit 0: парсер на любую неудачу писал один статус not_found, а под него попадали три разных события — канала нет, max.ru сменил формат, нас затроттлило. Пока они не разделены, скрипт ничего не измеряет — он производит число, похожее на измерение.

https://habr.com/ru/articles/1080198/

#MAX #мессенджер_MAX #парсинг #SvelteKit #SQLite #каталог_каналов #firstparty_данные #обработка_ошибок #антинакрутка #метрики

Гонка за исключением или как один except Exception может лишить сна на неделю

Сервис зависает, контейнер не отвечает, а в логах — только «обработанные» ошибки. Часто причина таких инцидентов скрывается в слишком широком except Exception , который мешает приложению корректно завершаться. Разберем, как правильно обрабатывать исключения в production‑воркерах и избежать подобных проблем. Читать разбор

https://habr.com/ru/companies/otus/articles/1071382/

#Python #исключения #обработка_ошибок #микросервисы #Kubernetes #Docker #backendразработка #production #очереди_сообщений #отказоустойчивость

Пагинация. Ошибки тестирования списков и курсоров

Пагинация ломается не только внутри запроса к базе. Это цепочка: бэкенд определяет порядок и границу страницы, фронт хранит курсор и объединяет ответы, а пользователь меняет фильтры, повторяет запросы и возвращается на экран. Разберём шесть ситуаций, в которых локальные проверки зелёные, а список целиком работает неправильно. Проверить пагинацию

https://habr.com/ru/companies/otus/articles/1070840/

#пагинация #автоматизация_тестирования #тестирование_API #E2Eтестирование #Playwright #курсорная_пагинация #интеграционные_тесты #гонки_запросов #тестирование_фронтенда #обработка_ошибок

Скрипт деплоя отчитался об успехе, а на сервере осталась старая версия: 5 ошибок в bash, которые допускают новички

Зелёный пайплайн ещё не означает, что деплой прошёл как надо. В Bash хватает ситуаций, где ошибка теряется, код возврата маскируется, а скрипт спокойно идёт дальше. Разберём типичные ловушки и способы сделать такие сценарии предсказуемее. Разобрать ошибки

https://habr.com/ru/companies/otus/articles/1068482/

#Bash #shellскрипты #Linux #обработка_ошибок #деплой #pipefail #ShellCheck #автоматизация

Структурированные логи в FastAPI: практический гайд от request_id до trace_id

Самая неприятная часть расследования инцидента начинается, когда нужные данные в логах вроде бы есть, но связать их между собой невозможно. Один запрос оставляет десятки строк, пользовательский контекст теряется, а события микросервисов живут каждый своей жизнью. На примере FastAPI соберём JSON‑логирование, в котором запрос можно проследить целиком, ошибки — фильтровать по типу, а задержки — анализировать по duration_ms .

https://habr.com/ru/companies/otus/articles/1067632/

#JSONлоги #структурированное_логирование #Python #FastAPI #logging #request_id #trace_id #обработка_ошибок #мониторинг #производительность

9 ошибок при создании и внедрении автоматизаций в n8n

Автоматизация в n8n может собраться за полчаса, а через несколько месяцев превратиться в процесс, который страшно менять. В статье — 9 ошибок проектирования и внедрения, из‑за которых такие сценарии становятся хрупкими, дорогими в поддержке и плохо передаются другим.

https://habr.com/ru/companies/otus/articles/1065750/

#n8n #автоматизация_процессов #автоматизация_бизнеспроцессов #lowcode #workflow #архитектура_автоматизаций #обработка_ошибок #безопасность_API #модульная_архитектура #версионирование

Стек отвечает «где упало», а вопрос был «что случилось»

В моей старой системе учёта валютной позиции больше двадцати лет стоял коммерческий инструмент трассировки от конторы, которая делала SoftICE. Он работал исправно, о каждой ошибке присылал письмо со стеком вызовов — и не помог мне ни разу. Недавно я наконец понял, почему так вышло, и ответ оказался до обидного простым.

https://habr.com/ru/articles/1068856/

#обработка_ошибок #дебаггинг #боль

Go прощает меньше, чем кажется: восемь ошибок, на которых спотыкается каждый новичок

Привет, Хабр! Go специально сделали маленьким языком. Ключевых слов немного, конструкций мало, за неделю осваиваешь синтаксис и начинаешь писать. Именно из-за этой простоты возникает ложное ощущение, что тут негде ошибиться — код компилируется, значит всё правильно. А потом оказывается, что компилятор пропускает целый класс вещей, которые в других языках он бы отловил или которые просто устроены не так, как ты привык. Цикл, который выдаёт не те значения. Слайс, который меняется сам собой. Горутина, которая молча теряет ошибку. Всё это компилируется и запускается, а ведёт себя не так, как ожидаешь. Собрал восемь ошибок, через которые проходит примерно каждый, кто приходит в Go из другого языка. Все — реальные, все встречаются в чужом (и своём) коде постоянно.

https://habr.com/ru/companies/otus/articles/1065500/

#golang #go #ошибки_новичков #горутины #управление_памятью #обработка_ошибок #слайсы

Ошибки не должны быть безмолвными: Sentry, Firebase Crashlytics и Datadog в одном Flutter‑приложении

Мобильное приложение может стабильно проходить тесты и всё равно падать у пользователей в сценариях, которые команда не успела предусмотреть. В статье разберём, как связать Firebase Crashlytics, Sentry и Datadog во Flutter‑приложении, чтобы собирать ошибки с контекстом, быстрее находить причины сбоев и видеть проблемы с производительностью до того, как они станут массовыми.

https://habr.com/ru/companies/otus/articles/1057544/

#Flutter #мониторинг_ошибок #обработка_ошибок #Firebase_Crashlytics #Sentry #Datadog #наблюдаемость #хлебные_крошки #стектрейс #перехват_исключений

Structured outputs, которые не работают: пять ситуаций, где схема есть, а гарантий нет

Strict‑режим включён, схема валидна, ответ успешно парсится — а в проде всё равно всплывают None , пропавшие ограничения и аргументы инструментов не тех типов. В статье разберём пять ситуаций, где Structured Outputs создают ложное ощущение надёжности, и посмотрим, какие проверки действительно стоит добавить в LLM‑пайплайн.

https://habr.com/ru/companies/otus/articles/1058384/

#структурированные_ответы #JSON_Schema #strictрежим #большие_языковые_модели #Pydantic #валидация_данных #OpenAI_API #вызов_инструментов #ИИагенты #обработка_ошибок

Полностью нечестное сравнение std::expected в C++23 и core::result::Result в Rust

Привет, Хабр! Воодушевившись статьёй std::expected в C++23: гайд по миграции с исключений на функциональный error handling , представляю собственную с переписанными примерами на Rust. Код в статье итеративно переписывается и улучшается.

https://habr.com/ru/articles/1057332/

#c++23 #rust #обработка_ошибок #типизация_ошибок #функциональный_подход

std::expected в C++23: гайд по миграции с исключений на функциональный error handling

Исключения удобны, пока ошибки не становятся обычной частью логики. В C++23 для таких случаев есть std::expected : он явно показывает в сигнатуре, что функция вернёт либо результат, либо ошибку. Разберём, как перейти к этому подходу без переписывания проекта с нуля.

https://habr.com/ru/companies/otus/articles/1054592/

#C++23 #обработка_ошибок #исключения #функциональный_подход #RAII #типизация_ошибок #legacyкод

[Перевод] Исключения в реактивных системах

Очень часто программисты не думают о чрезвычайных ситуациях. Особенно печально, когда это не разработчики приложений, а авторы библиотек и фреймворков. Ошибок, конечно. не должно быть, как и других неприятностей в жизни, однако они иногда случаются. Вина ли это программиста, браузера, его расширений, операционной системы, звездного ветра — неважно. Нужно уметь принимать удар и не прятать голову в песок. Но в разных библиотеках мы сталкиваемся с очень разным поведением… Исключить эту статью из непрочитанных

https://habr.com/ru/articles/1048968/

#реактивное_программирование #обработка_ошибок

Ваше сообщение об ошибке читает уставший человек в два часа ночи

Два часа ночи, у разработчика горит релиз, он подключает ваш API — и получает в ответ голое «invalid_request». Что не так, почему, что делать — ни слова. Сорок минут гаданий и злое письмо в поддержку. Разбираем, как сделать опыт разработчика (DX) человеческим: как переписать ошибки по стандарту RFC 9457, но для живого человека; почему время до первого успешного вызова — главная метрика онбординга; и отчего предсказуемый, «скучный» API — это комплимент. С готовым шаблоном, который можно прикрутить к себе сегодня.

https://habr.com/ru/articles/1042850/

#api #dx #developer_experience #rest #обработка_ошибок #error_handling #RFC9457 #problem_details #ttfhw #онбординг_разработчиков

Пять проблем Bash, которые ломают скрипты в самый неудачный момент

Bash прощает многое: можно писать кривые скрипты годами, и они будут работать. Кривизна вылезает, как правило, в самый неподходящий момент. В статье рассмотрим пять ошибок, которые встречаются даже в проектах с опытными админами, потому что поведение Bash в этих местах неинтуитивно и плохо документировано в одном месте.

https://habr.com/ru/companies/otus/articles/1039854/

#Bash #Linux #скрипты #shell #subshell #set_e #pipefail #trap #nullglob #обработка_ошибок

Outbox-паттерн для мобильного мессенджера: как Telegram не теряет сообщения и почему ваш код их теряет

Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов. Сценарий с которого всё началось у меня. Пользователь в чате выбирает большое видео, нажимает отправить. Видео начинает грузиться. Пользователь нетерпеливый, прокручивает вверх посмотреть переписку, потом переходит в другой чат, потом возвращается. Что должен он увидеть? В Telegram он увидит свой видео-бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения , потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает. Это боль которая лечится не "правильным useState", а отдельным архитектурным слоем . Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.

https://habr.com/ru/articles/1034690/

#react_native #мессенджер #optimistic_update #outbox #мобильная_разработка #архитектура #telegram #асинхронность #обработка_ошибок #retry

[Перевод] Создание MCP‑серверов на FastMCP: 7 ошибок, которых стоит избегать

FastMCP позволяет быстро собрать MCP‑сервер, но скорость легко оборачивается ошибками: лишние токены, слабые схемы, сырые API‑примитивы, плохая обработка ошибок и риски безопасности. В статье разбираем 7 проблем, из‑за которых LLM‑агент начинает путаться, ломать сценарии и требовать лишних подтверждений, — и показываем, как их исправить.

https://habr.com/ru/companies/otus/articles/1032890/

#MCP #FastMCP #ИИагенты #LLM #Python #API #безопасность #обработка_ошибок #токены #проектирование_инструментов

Error 500? Как вместо кодов получать подробные сведения обо всех ошибках сразу

Привет, Хабр! Меня зовут Артём Корсаков. Я пишу на Scala и руковожу группой разработчиков в компании «Криптонит» , а также веду Scalabook — русскоязычную базу знаний по Scala и функциональному программированию. В этой статье расскажу про обработку ошибок в библиотеке http4s на Scala 3. Мы разберём, как настроить декодирование запросов так, чтобы клиент получал не просто код “500” или “422” с общим сообщением, а сразу видел развёрнутый список всех проблем в запросе. Например, что логин уже занят, пароль содержит недопустимые символы, а капча не введена. Пожалуй, самая раздражающая ошибка — это получение кода “500” в ответ на запрос, который ты десять раз перепроверил, сверился с документацией и уверен на все 100%, что запрос рабочий. Даже на 110%! В такие моменты раздражённо думаешь: “Что же этому серверу надо? Я же чётко сформулировал запрос! Ответить на этот вопрос порой сложно. Например, я хочу зарегистрироваться на сайте, ввожу логин/пароль и получаю сообщение "Internal Server Error". Первое желание – тут же покинуть сайт и поискать более дружелюбный. Давайте подумаем, как можно сделать сообщение об ошибке более информативным . Для этого будем использовать Scala 3, уточняющие типы и http4s . Представим, что мы создаём API сервиса авторизации, который (помимо прочего) должен регистрировать новых пользователей. Для начала определим структуру данных для создания нового пользователя.

https://habr.com/ru/companies/kryptonite/articles/1026698/

#функциональное_программирование #scala #http4s #обработка_ошибок #декодирование_запросов #backend

[Перевод] Возвращаем информативные ошибки API

Ошибки в API часто воспринимаются как второстепенная часть контракта – до тех пор, пока интеграции не начинают ломаться в самых неожиданных местах. В этот момент выясняется, что одного HTTP-кода недостаточно: без ясной структуры и контекста ошибки превращаются в источник неопределённости и лишней работы. В статье разберём, как проектировать ошибки как полноценный элемент API – с понятной семантикой, единым форматом и возможностью для автоматической обработки.

https://habr.com/ru/companies/otus/articles/1018008/

#API_ошибки #обработка_ошибок #REST_API #HTTP_статускоды #проектирование_API #код_ошибки #сообщения_об_ошибках #валидация_данных #интеграции_API

Kotlin и Arrow: функциональное программирование с Either, Validated и эффектами

Сегодня расскажем про библиотеку Arrow в Kotlin. Arrow привносит в Kotlin крутые штуки из функционального программирования: типы вроде Either и Validated для работы с ошибками, эффекты для безопасной работы с внешним миром, ну и много всего. Звучит мощно, но когда за это действительно стоит браться?

https://habr.com/ru/companies/otus/articles/989658/

#kotlin #Arrow #android #функциональное_программирование #обработка_ошибок #валидация_данных #типизация_ошибок

[Перевод] Тихий Promise, который убьёт ваш сервер Node.js

У вас есть продакшен-сервер. Он спокойно работает часами. А потом внезапно падает. Без предупреждения, без graceful-деградации. Просто мёртв. Виновник? Одна строчка кода, которая выглядит совершенно безобидно...

https://habr.com/ru/articles/988132/

#nodejs #промисы #асинхронность #promise #await #async #javascript #typescript #error_handling #обработка_ошибок

Избавляемся от ошибок Segmentation fault из-за переполнения стека в С++

Развивая идею доверенного языка программирования я пришел к выводу, что за счет ограничений синтаксиса и создания соответствующих проверок в статическом анализаторе кода, можно защититься практически ото всех технических ошибок, кроме двух - контроль динамически выделяемой памяти и переполнения стека. Причем, если для подсчета ссылок в рантайме, решения существуют, то контроль переполнения стека невозможно сделать не только во время анализа исходного текста программы, но это практически невозможно и во время выполнения приложения! Ведь ошибка переполнение стека (stack overflow) - это всегда фатально, так как не существует способа поймать и обработать эту ошибку изнутри выполняемой программы, чтобы потом продолжить её выполнение как ни в чем не бывало. Существует ли хотя бы теоретическая возможность защититься от ошибок переполнения стека и сделать из нее обычную ошибку (исключение), которую можно поймать (обработать) в самом приложении, чтобы была возможность продолжить выполнение программы без боязни последующей ошибки сегментации (segmentation fault) или повреждения стека (stack smashing)?

https://habr.com/ru/articles/983394/

#переполнение_стека #segmentation #segmentation_fault #stack_overflow #ошибки #исключения_в_c++ #обработка_ошибок #надежное_программирование #сезон_ии_в_разработке

Как обрабатывать исключения в Java

Обработка исключений — одна из фундаментальных тем в Java, с которой сталкивается каждый разработчик. Правильная работа с ошибками не только делает приложение стабильным, но и значительно упрощает его отладку и поддержку. В отличие от многих других языков, Java имеет строгую и продуманную систему исключений, которая делит все ошибки на проверяемые (checked) и непроверяемые (unchecked). В этой статье мы подробно рассмотрим иерархию исключений, их типы, лучшие практики обработки, а также распространенные антипаттерны. Чтобы статья была практико‑ориентированной, мы разберем реальные примеры кода, которые покажут, как правильно выбрасывать, обрабатывать и создавать собственные исключения.

https://habr.com/ru/companies/otus/articles/971192/

#java #обработка_исключений #исключения_в_Java #checked_исключения #unchecked_исключения #RuntimeException #обработка_ошибок #иерархия_исключений

conway-errors: порядок в ошибках как часть архитектуры проекта

Однажды при работе с крупной кодовой базой одного фронтенд-приложения я заметил, что функционал постепенно группируется относительно команд (доменов). Каждая из таких групп функционала постепенно накладывает собственные ограничения на архитектуру. Как оказалось, обработка ошибок при сравнении кода двух разных команд неоднородна. В одном случае разработчики структурировали ошибки стандартным наследованием JS/TS, в другом были использованы перехваты возникающих ошибок и логирование. Стало ясно, что нам требуется обобщить подход к тому, как мы структурируем (называем, наследуем) и выбрасываем ошибки. Как показала практика, соглашений о кодировании недостаточно. Что мы хотели получить?

https://habr.com/ru/articles/961184/

#ошибки #ошибки_в_коде #обработка_ошибок #архитектура_приложений #фронтенд #бэкенд

Хватит писать try/catch вокруг fetch: история о том, как я устал ловить ошибки

Каждый фронтендер знает эту боль: пишешь запрос через fetch - и автоматически добавляешь try/catch . Где-то ловишь TypeError , где-то 500-й статус, где-то подвисший запрос с AbortController . В итоге половина кода в проекте - это обработка ошибок, а не бизнес-логика. Я прожил с этим годами. Чем больше становился проект, тем больше росла копипаста: таймауты, ретраи, проверки на res.ok , костыли для разных браузеров. Одно и то же, снова и снова. И вот в какой-то момент я понял: проблема не в том, что ошибки случаются. Проблема в том, что сам fetch вынуждает нас ловить их вручную, каждый раз, в каждом запросе. Так появилась библиотека @asouei /safe-fetch . Маленькая (3kb), без зависимостей, но с тем, чего нет у самого fetch : общий таймаут, умные ретраи, нормализованные ошибки и поддержка Retry-After . 🌟 Библиотека добавлена в Awesome TypeScript — один из крупнейших мировых списков лучших TypeScript-проектов Как я решил проблему

https://habr.com/ru/articles/943732/

#fetch #javascript #typescript #обработка_ошибок #http_запросы #retry #timeout #frontend #axios #open_source

[Перевод] async let vs Task group

В Swift для структурированной конкуренции используются async let и группы задач (task group). Хотя обе конструкции позволяют запускать параллельные операции, они по-разному управляют жизненным циклом задач. Сегодня мы разберём эти различия на примерах.

https://habr.com/ru/companies/otus/articles/928172/

#ios #swift #async_let #Task_group #параллелизм #конкуррентность #асинхронность #swift_concurrency #iOSразработка #обработка_ошибок

Обработка ошибок в Go

Обработка ошибок — это один из самых важных аспектов написания надёжного кода. В Go к этому вопросу подошли нестандартно: вместо традиционного механизма try/catch , как в Java или Python, ошибки просто возвращаются как значения. Изначально это может показаться странным, но на практике этот подход делает обработку ошибок более явной и честной. В этой статье мы разберёмся с тем, когда стоит использовать panic , какие есть распространённые ошибки при его использовании и как правильно обрабатывать исключительные ситуации в Go.

https://habr.com/ru/articles/916904/

#ошибки_в_go #обработка_ошибок #go #golang #обработка_ошибок_в_go