Треды тебе не гарантируют порядок выполнения

неаверное всетаки не race conditions

Тогда я не понял проблему

Сейчас опишу полностью свою ситуацию

Есть функция в которую передается  массив c id. Перед функцией к этому массиву применяется uniq. В базе данных стоит ключ на уникальность этого ID.  Внутри самой функции я проверяю что если какойто id уже есть в базе данных, то я его просто скипаю. Так вот у меня есть подозрения что иногда получается так что два воркера запускаются одновременно и проверка на уникальность id в БД уже прошла на стороне рельс, и валится на этапе записи в БД

Могу псевдокод накидать если неясно расписал

никак ты это не проверишь

У меня приказ

надо на стороне рельсов заворачивать в rescue ActiveRecord::Rollback, смотреть его причину, разворачивать ошибку от постргеса и если там написано unique key violation - то что-то делать самому (перегенеривать там или шот такое)

делай фэйл-позитив логику, если нарушил констреинт - игнорь
если не хочется - залокайся, выстрой воркеры в очередеь по локу в бд (накинул идеи)

а ну еще вроде можно advisory lock делать

на них и был намек у меня

но норовишь плодить тонну локов, а если они еще и xact - тонну транзакций (если твои джобы пулеметят)

а там если логика будет долгая - то боль потом будет 🙂

Понял, всем спасибо

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

Привет, есть кто работал с rspec_api_documentation? Не пойму в чем прикол создания групп

Я ожидал такого поведения, создаю к примеру группу admin, далее в этой группе ее взаимодействие например с сущностью Order, потом все генерируется и в документации я вижу вложенность типа Admin -> Order