Почему в вкладке Network DevTools не видно запроса после отправки формы при ответе 200?
Что проверяют
Знаете ли вы, как устроена сама панель Network, и понимаете ли, что ответ 200 это уже доказательство: запрос был. Вопрос про то, где вы будете искать, а не про то, кто виноват.
Как отвечать
Идти сверху вниз, от самого частого.
Запись и фильтры. Панель могла не писать: запись остановлена или лог очищен. Фильтр по типу прячет лишнее, и если выбран Fetch/XHR, обычная отправка формы там не появится никогда: браузер отправляет её как навигацию, и строка будет с типом Doc. Забытый текст в поле фильтра и включённая инверсия дают тот же эффект.
Переход после отправки. Обычный submit уводит на другую страницу, и без включённого сохранения лога записи стираются вместе с нужной строкой.
Контекст. Форма в iframe или во всплывающем окне пишет в свой контекст, и в селекторе сверху надо выбрать нужный фрейм. Запрос мог уйти из Service Worker, тогда искать его надо в его собственной панели.
Особые способы отправки. navigator.sendBeacon и fetch с флагом keepalive при уходе со страницы легко пропустить глазами, а у первого ответ вообще не читается.
Если строка не нашлась, взять внешнего арбитра: прокси или экспорт сетевого лога, и сверить с логами сервера по времени и идентификатору запроса.
Где спотыкаются
Ищут в фильтре Fetch/XHR и делают вывод, что запроса нет. Форма без JavaScript уходит документом, и в этом фильтре её не будет ни при каких условиях.
Второе: не включают сохранение лога до воспроизведения. Включить после того, как всё произошло, бесполезно: строка не вернётся, нужен повтор сценария целиком.
Третье: пишут в баге «фронт не отправляет запрос», имея на руках ответ 200. Формулировать надо наблюдаемое: форма отправлена, сервер вернул 200, в панели запрос не отображается. Иначе разработчик потратит день на опровержение придуманной причины, а настоящая останется ненайденной.