[TThanos3000]

Что изменено

Если эксперт отправляет первую оценку одновременно с подтверждением удаления лидера из программы, оценка теперь может завершиться. Удаление получает 409 и требует новый просмотр заявок вместо взаимной блокировки запросов.

Зачем

Дополнительный конкурентный сценарий выявил цикл: удаление удерживало Project FOR UPDATE и ожидало программу; отправка оценки удерживала программу и при commit ожидала KEY SHARE проекта для проверки FK.

Реализация

Блокировка проекта заменена на FOR NO KEY UPDATE. Она сохраняет сериализацию изменений лидера/заявок, но допускает FK-проверку новой оценки. Порядок Project → программы → регистрации, проверка прав и подписанного снимка остаются прежними. После commit оценки снимок меняется, поэтому удаление отклоняется без потери данных.

API

Контракт не меняется. Исправляется конкурентное выполнение POST удаления регистрации из API #804.

UI

Не меняется; существующий 409 показывает требование повторного подтверждения.

Permissions

Не меняются. Program scope, actor, preview и повторная проверка прав сохранены.

Проверки

• Детерминированный PostgreSQL тест воспроизводит ошибку до исправления: deadlock detected.
• После исправления: 54 теста управления/экспертов, включая две конкурентные операции, проходят на PostgreSQL.
• flake8 и black измененных файлов проходят.
• PostgreSQL CI39503425238: 1234 теста без пропусков и 39 отдельных проверок блокировок/откликов — успешно.
• Совместимость CI39503414698: 1234 теста, 28 ожидаемых DB feature skips в SQLite — успешно; lint прошел.
• DEV deploy39505019377: исходники b2070bc точно соответствуют проверенному дереву; pending0, runtime access, HTTP smoke, Celery pong — успешно. После выкладки 10 анонимных API/SPA проверок прошли.

Acceptance criteria

• AC7: новая оценка сохраняется; устаревшее удаление требует свежий preview; регистрация и заявка остаются.
• Конкурентное повторное удаление по одному preview по-прежнему дает один успех и один409.
• AC12: обычная DEV выкатка и фактический smoke.

Не проверено

Конкурентные записи над настоящими dev-пользователями не выполнялись. Сам конфликт воспроизведен детерминированно на изолированном PostgreSQL до исправления и успешно проверен после; реальный API проверен безопасными анонимными GET.

Риски / migration

Миграции и клиентские изменения не требуются. PostgreSQL поддерживает NO KEY UPDATE; тест помечен соответствующей DB feature и не претендует на проверку row locks в SQLite. Никакие реальные оценки или участники не менялись в QA.