Сейчас можно создать дублирующие записи в external_site_users с одинаковым external_id через post-запросы к эндпоинтам "api/auth/external_user_registration/fund" или "api/auth/external_user_registration/volunteer".
Нужно запретить такое поведение.
Первый вариант бага:
Вручную создать в таблице external_site_users запись с external_id, но без значения id_hash (или удалить id_hash для записи, созданной через эндпоинт). Такие записи есть в БД на проде.
Обратиться с post-запросом к "api/auth/external_user_registration/fund" или "api/auth/external_user_registration/volunteer" так, чтобы в теле запроса значение user_id было такое же как external_id в записи в БД.
В БД появится запись с дублирующим external_id. При этом была ли первая запись (без id_hash) архивной или нет, не влияет на появление второй записи.
Корректное поведение: нужно обновлять первую запись с совпадающим external_id (которая была без id_hash).
Второй вариант бага:
Создать в таблице external_site_users первую запись через эндпоинт.
Обратиться с post-запросом к "api/auth/external_user_registration/fund" или "api/auth/external_user_registration/volunteer" так, чтобы в теле запроса значение user_id было такое же как external_id в записи в БД, но id_hash отличался от id_hash первой записи.
В БД появится запись с дублирующим external_id. При этом была ли первая запись (без id_hash) архивной или нет, не влияет на появление второй записи.
Корректное поведение: нужно возвращать ошибку "Пользователь с таким user_id уже существует."
Сейчас можно создать дублирующие записи в external_site_users с одинаковым external_id через post-запросы к эндпоинтам "api/auth/external_user_registration/fund" или "api/auth/external_user_registration/volunteer". Нужно запретить такое поведение.
Первый вариант бага:
Корректное поведение: нужно обновлять первую запись с совпадающим external_id (которая была без id_hash).
Второй вариант бага:
Корректное поведение: нужно возвращать ошибку "Пользователь с таким user_id уже существует."