N, вопрос не в решении конкретной ситуации, а в написании тестов для проверки исправления + отлавливания потенциальных будущих ошибок превентивно.
Конкретно эта ошибка уже исправлена (блокировкой, потому что неизвестны побочные эффекты использования внешнего сервиса).
tukreb, sleep поможет не в исправлении ошибки, а в написании теста, воспроизводящего ошибку, когда два потока теста дернут соответствующие методы контроллеров.
в моем случае гонка возникает из-за нескольких сеансов одного пользователя на разных устройствах или нескольких одновременных запросов с одного устройства. ну и дедлоки или излишние блокировки (потерю параллельности работы нескольких не мешающих друг другу пользователей) потенциальные тоже легче тестировать, замедлив все запросы к бд.
Роман Безруков, Alexey Dmitriev, ну вот у меня было такое на терминальном серваке. проще было повесить рестарт спулера на каждую ночь, чем понимать, почему раз в несколько дней/недель перестает печатать. с тех пор никаких проблем. вероятно у кого-то из пользователей к компу подключен принтер с кривыми дровами (при этом глюки начинаются не сразу), но при том что пользователи сидят из дома и никакой стандартизации - проще так.
Everything_is_bad, ну вот кейс - был эндпоинт, в начале было получение информации из БД, проверка, если ок, то создание и возврат данных. потом в процессе добавилось обращение к внешнему сервису, причем добавили его в середину между проверкой и созданием (зачем два раза базу дергать, на создание и обновление?) сущности.
при реальной эксплуатации заметили двойные сущности в БД, стали разбираться, получилось понять, как такое возможно и вставить нужное.
В принципе, замедлить запросы можно на уровне всей системы, переопределением своей реализацией соответствующих фасадов (да хотя бы и просто sleep в нужные места, хоть и костыль). Задача в добавлении тестов для проверки корректности внесенных изменений для исправления подобных ошибок, выявленных в эксплуатации и для "упреждающего" тестирования потенциально проблемных мест при параллельной работе нескольких пользователей. И встраивание этого в общий процесс тестирования (в идеале - в php artisan test)
Everything_is_bad, ну да. и вот это и надо протестировать - что все нужные блокировки выставляются, что ненужные - не выставляются. Что не возникает дедлоков и лишних задержек при параллельной работе.
Everything_is_bad, с регистрацией может быть не самый очевидный пример, часто email имеет уникальный индекс и идет ошибка, да (но и это надо протестировать). Но бывают случаи, когда пользователь может быть удален и создан заново, например при регистрации по номеру телефона - когда пользователь долго не пользуется номером и потом номер передается другому человеку. Тогда признак уникальности надо снять и добавить SoftDeletes.
Или с формированием заказа из корзины на двух устройствах одновременно (да даже и с одного при двойном нажатии).
Да мало ли случаев. Я спрашиваю про общий подход - есть ли удобный вариант в инфраструктуре laravel или надо изобретать что-то?
если в браузере открыть http:////ws/ScheduleExchange.1cws?wsdl то все работает? а то синтакс контроль в модулях ws и http может глючить а по факту модуль не "компилируется"
