#race_condition — Public Fediverse posts

Вскрытие ноу‑код сметы за 500$ или как купить «АИ — ассистента» который сожрёт весь бюджет заказчика

Привет, Хабр! Я разработчик из Минска (работаю официально, в статусе НПД). Занимаюсь автоматизацией на связке Self‑Hosted n8n + Redis. Внедряю автономных ИИ‑агентов для мессенджеров и связываю их с amoCRM. Поделюсь, как говорится, «мясом» из своей практики. В статье я максимально постараюсь отразить и технический абсурд плавно переходящий в явное кидалово от инфомошенников. Перед началом сразу обозначу, как говориться, на берегу: во‑первых — это не хейт и не попытка кого‑то «разоблачить» . Ленты мессенджеров завалены рекламой от «ИИ‑агентств» и «продавцов успешного‑успеха», которые громко кричат про «...ваш цифровых сотрудников за пару дней...». У меня нет раскрученного профиля с красивыми публикациями, но, есть обычная практика. Данный разбор — это попытка показать (а может кому‑то и знакомо), что скрывается за красивыми нагенерированными видосами и контентом и почему, доверив реальный проект таким «спецам» обойдётся дорого. Во‑вторых — все упоминания брендов и платформ в статье — не реклама и не антиреклама. Названия систем я оставил исключительно ради сохранения контекста, да и в принципе живого отражения примера. История статьи началась, наверное можно сказать в 2 этапа. На первом этапе , который был ещё наверное в марте этого года, ко мне обратился заказчик с интересным ТЗ: стек Instagram+ amoCRM + Google Sheets при плотном трафике до 5000 диалогов в месяц (таргет что тогда, что по сей день заходит «на ура»). Причём сёстры (заказчик — это семейный бренд ателье дизайнерских украшений) своими силами опробовали «... платформы где платишь подписку и в соответсвии с трафиком выбираешь соответствующий пакет услуг . Итог в который после первого дня триала по самым средним подсчётам вышел бы 1100$ в месяц расхода (!). Поскольку моя статья не о том какая архитектура была в итоге у них развёрнута, так что пойдём дальше.»

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

#n8n #Redis #Debounce #amoCRM #ИИагенты #автоматизация_бизнеса #вебхуки #конструкторы_ботов #Race_Condition #искусственный_интеллект

Двойная бронь: как мы поймали гонку в записи и закрыли её EXCLUDE-констрейнтом

Я делаю сервис онлайн-записи для салонов красоты: клиент записывается в чат-боте или на странице, а запись падает в расписание мастера. Однажды мастер написал мне: на 15:00 к ней пришли два клиента. Оба записаны, оба уверены, что слот их. Классическая двойная бронь — и классическая race condition. Разберу, почему наивная проверка «свободно ли время?» не спасает, и как мы закрыли дыру двумя слоями: advisory-lock и EXCLUDE-констрейнтом в PostgreSQL. По пути — один неочевидный подвох с IMMUTABLE , на который легко напороться.

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

#PostgreSQL #race_condition #двойная_бронь #EXCLUDE_constraint #btree_gist #advisory_lock #SAVEPOINT #tstzrange #целостность_данных #конкурентность

Linux Kernel 0-Day in net/sched: AI-Assisted Research Reveals CVE-2026-53264 Race Condition - https://www.redpacketsecurity.com/ai-assisted-bug-hunt-uncovers-linux-kernel-0-day-in-net-sched/

#threatintel #Linux_kernel #Local_privilege_escalation #Race_condition

Я продал одно место на концерт 20 раз. Разбираемся, как правильно защититься от race condition в Spring Boot

Однажды я решил проверить на практике байку, которую слышал на десятке собеседований: “у нас на проде было такое-то место продано дважды, потому что…” . Оказалось, воспроизвести это не просто легко — это воспроизводится настолько надёжно и настолько наглядно, что грех было не довести дело до конца: взять систему бронирования мест, специально сломать её, замерить, насколько плохо, а потом последовательно починить тремя разными способами — и честно сравнить, что каждый из них стоит по производительности. Спойлер: один из результатов оказался прямо противоположным тому, что я ожидал увидеть.

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

#java #hibernate #spring_data_jpa #redis #optimistic_locking #pessimistic_locking #race_condition #spring_boot

Realtime-чат без WebSocket: long-polling, гонки переподключения и дубли пушей

Бывает, что realtime на проекте уже нужен, а WebSocket по каким-то причинам нет. Остаётся long-polling: клиент шлёт «бесконечный» HTTP-запрос, сервер держит его, пока не появятся новые сообщения, отвечает - и клиент тут же открывает следующий. Звучит просто, ровно до первого запуска на живом устройстве где-нибудь в метро. Дальше начинается то, ради чего и написана статья: гонки при переподключении, дубли локальных пушей и два независимых потока сообщений в одном ответе. Разбираю на примере реального iOS-сервиса, который я разрабатывал более 5 лет

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

#longpolling #Comet #realtime #WebSocket #race_condition #exponential_backoff #jitter #pushуведомления #GCD

Race Condition в веб-приложениях: три типа уязвимости и как их находить

Для начала разберёмся, что такое Race Condition и почему эта уязвимость заслуживает внимания. Race Condition — это класс уязвимостей, которые возникают из-за того, что сервер обрабатывает несколько запросов одновременно без должной синхронизации. Когда два или более запроса приходят на сервер в один и тот же момент и затрагивают одни и те же данные, между ними происходит коллизия. Результаты такой коллизии могут быть разными — от незначительных багов до критических уязвимостей, которые позволяют обойти проверки безопасности, списать средства дважды, получить доступ к чужому аккаунту или превысить установленные лимиты. Перейдём к тому, какие виды этой уязвимости вообще бывают. Можно выделить 3 вида:

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

#Race_Condition #гонка_состояний #TOCTOU #веббезопасность #bug_bounty #Burp_Suite #Turbo_Intruder #singlepacket_attack #account_takeover #уязвимости

Реализация Statefull команд в Telegram API

Java Telegram API обманывает разработчиков дубликатами запросов при отключении интернета? Мы команда разработки телеграмм ботов, которая смогла придумать решение для работы с дубликатами в Statefull командах Telegram API используя REST. Прошли путь от наивного решения до работающего продукта.

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

#telegram_api #telegram_api_manual #telegram_api_request #stateless #statefull #race_condition #идемпотентность #идемпотентность_запросов

Кэширование в Symfony: как мы сломали авторизацию и починили ее через Lock

Привет, Хабр! На связи команда «Исходного Кода». Когда бэкенд на Symfony начинает тормозить, одним из первых инструментов оптимизации почти всегда становится кэширование. И это логично: правильно настроенный кэш круто снижает нагрузку на базу данных, режет latency API и убирает лишние ресурсоемкие операции внутри приложения. Но на практике мы редко ограничиваемся простым cache->get() и базовым TTL, особенно когда приложение крутится не на одном сервере, а в Kubernetes-кластере с пачкой внешних API и жесткой конкуренцией запросов. В таких условиях кэш - это уже не только про скорость, но и про синхронизацию состояния между процессами и pod'ами.

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

#Symfony_Lock #Symfony_Cache #JWT_кэширование #race_condition #distributed_lock #Memcached #401_Unauthorized #doublecheck

Idempotency keys: 5 граблей, которые мы поймали на проде

Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно три ответа провайдера 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку. Мы делали B2B-платформу для деловых поездок: бронь авиа, отели, трансфер, страховка, в финале – оплата корпоративной картой через платежный шлюз. С этой ночи началась история, которая закончилась переписыванием всего платёжного слоя нашего booking-сервиса. По дороге мы поймали 5 граблей.

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

#идемпотентность #idempotency #платежи #распределённые_системы #NET #C# #API #intentkey #race_condition #грабли

Reactive Programming не спасёт вас. Если вы не решили эти 5 проблем — у вас просто медленный монолит с Flux

Нагрузочный тест. 10 000 событий в секунду, три инстанса сервиса, Spring WebFlux, Project Reactor — всё как по учебнику. Смотрю на метрики. Event loop завис на 800 миллисекунд. В хранилище — данные за более позднее время перезаписаны более ранними. WebSocket-сессия потеряла сообщения под нагрузкой. Два из трёх инстансов не получают события. Код написан на WebFlux. Но реактивности в нём не было. Я строил сервис потоковой доставки данных в реальном времени: тысячи источников → обработка → тысячи WebSocket-подписчиков. Каждая из пяти проблем ниже была невидима на демо. Каждая проявилась под нагрузкой. И каждая из них — не баг фреймворка. Это паттерны которые нужно знать заранее. Узнать личный опыт

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

#webflux #websocket #java #latency #deadlocks #race_condition #flux #redis #kafka_apache #async

Code Review Horror Stories. Часть 1: Concurrency & Memory в Go-сервисе

Продолжение прошлой статьи про ошибки на Go-собесах . В тот раз — про лайв-кодинг. Теперь — про code review: когда дают готовый сервис на ~150 строк и говорят “найди что не так, у тебя 30 минут”. Разберём по косточкам реальный код с собеседования — микросервис трекинга рекламных кликов. Багов набралось 21, поэтому делю на две части. Первая — про самое страшное: concurrency, гонки, утечки памяти и горутин. Это то, что роняет сервис в проде. Часть 2 — про API design, ошибки и graceful shutdown — выйдет следом. Актуально для Go 1.26. Из 21 бага на собесе я нашёл 18. Три самых тонких пропустил — потом, дома, перечитал спокойно и выписал. В этой части про concurrency пропустил один — TOCTOU race в дедупликации. Остальные семь — поймал. Расскажу как искал и какими красными флагами зацепился.

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

#go #golang #code_review #собеседование #конкурентность #goroutine #race_condition

Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2

В прошлой статье я немного слукавил, сказав, что мы будем разбирать атомики, барьеры и системные вызовы. Я пару дней поразмышлял и осознал – а зачем вообще это объяснять, если мы даже не знаем про причину их возникновения и проблемы, которые они решают В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?” Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы) В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник Многозадачность Хоть мы и развенчиваем в этом цикле абстракции, придется немного к ним вернуться. Но ненадолго! Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию: Есть какое-то количество ГБ RAM Есть 1 ядро CPU Соответственно в один момент CPU может выполнять ровно 1 набор инструкций Но почему-то всё во времена одноядерных CPU работало непрерывно… На самом деле нет! Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность !

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

#assembler #go #multithreading #multitasking #race_condition #cache_contention #cpu #ram #linux

Начинаем в багбаунти: как найти ошибки в бизнес‑логике

Всем привет! Меня зовут Роман. В ИТ я больше семи лет: начинал с разработки, а теперь занимаюсь AppSec и параллельно пробую себя в багхантинге. Сейчас вхожу в топ-25 рейтинга на Standoff Bug Bounty. Здесь я выступаю как начинающий исследователь багов и буду рад поделиться своими наработками. Сегодня обсудим уязвимости бизнес‑логики — сложные и часто недооцененные ошибки, способные привести к серьезному ущербу. Разберем, как их находить, почему они опасны и что делает охоту за ними в багбаунти такой увлекательной. Погнали!

https://habr.com/ru/companies/pt/articles/1014346/

#bug_bounty #broken_access_control #race_condition #jwt #dos #standoff #bugs #api #fuzzing #auth_bypass

Нагрузочное тестирование с нуля: наши грабли, гонка за токеном и рабочий чек-лист

Привет, хабровчане! Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. Все мы знаем эту боль: фича идеально работает на деве и предпроде, проходит все тесты, а когда под реальной нагрузкой на нее заходят сотни пользователей одновременно - все начинает тормозить, сыпать ошибками или просто падать. Чтобы этого избежать, мы решили, что НТ должно стать обязательным этапом для всех фичевых задач, которые серьезно меняют логику, затрагивают запросы к серверу, кэширование или обработку данных. Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

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

#нагрузочное_тестирование #race_condition #кэширование_данных #memcached #оптимизация_производительности #чеклист_нагрузочного_тестирования #кейс_нагрузочного_тестирования #гонка_процессов #метрики #анализ_работы_web_сервисов

Когда ошибка становится наставником: почему баги прошлого нередко полезнее любого чек-листа

Каждый разработчик хотя бы раз в жизни сталкивался с ситуацией, когда баг, который вроде бы уже исправлен, неожиданно возвращался в продакшен. В этой статье я расскажу о тех случаях, когда ошибки служили для меня не провалом, а очень настойчивым, но полезным учителем. Да, иногда именно они объясняют архитектуру, принцип работы систем или забытый corner case лучше самых толстых документаций. Эта статья не учит идеализму — наоборот, она про то, как ценить несовершенство.

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

#ошибка #баг #отладка #архитектура #опыт_разработчика #race_condition #обработка_данных #очереди #продакшен #надежность

Concurrency testing — отлавливаем состояния гонки

В статье разберём некоторые техники обнаружения плавающих багов, вызванных конкурентностью. Сделаем подход к автоматическому тестированию устойчивости веб-сервисов к различным race condition. Примеры будут на python + asyncio + sqlalchemy, но эти подходы применимы к любым моделям конкурентности, которые подвержены состояниям гонки.

https://habr.com/ru/companies/tochka/articles/865086/

#race_condition #python #asyncio #fuzzing #testing

Filesystem race condition. Незапланированное решение задачи на Кубке CTF 2024

В статье рассмотрим нестандартное решение задания с Кубка CTF 2024 на бинарную эксплуатацию – “ R4v5h4n N Dj4m5hu7 ” и обойдем проверку реального пути к файлу c помощью filesystem race condition

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

#race_condition #уязвимости #ctf

Ловушки volatile, DCL и синхронизации в Java

А что если окажется, что простые знания на самом деле более нюансированные, а старые знакомые, такие как Double-checked locking, являются неоднозначными? Именно на такие мысли наталкивает изучение кода реальных проектов. Результаты этого исследования мы и рассмотрим в этой статье.

https://habr.com/ru/companies/pvs-studio/articles/819625/

#volatile #java #dcl #doublechecked_lock #doublechecked_locking #race_condition #dbeaver #parallel_programming #параллельное_программирование #состояние_гонки