Бывает важно отличать, что именно произошло - проблема с интернетом, проблема с бакэндом или проблема с клиентской частью. Т.е. сначала необходимо попытаться определить именно это.
- если бакэнд вернул ошибку, значит проблема не в сети
- чтобы покрыть ряд проблем с клиентом - можно таскать в каждом запросе и ответе идентификатор версии приложений, чтобы сервер смог логировать несоответствия (например проблемы с кешированием файлов фронтэнд кода, при неправильной организации ссылок на него, т.е. без хеша в имени например)
- клиент само может сгенерировать по своей логике ошибки (если используются javascript или аналоги), главное сообщить об этом серверу (разработчики должны знать о проблемах сразу, а не ждать когда клиенты им позвонят)
По каждой причине может потребоваться соответствующая реакция. Хорошим методом является возможность повторить ошибочную операцию, а если она критична к дублированию (чтобы не создавать дубликат новых постов на форуме например), в самом сообщении добавлять уникальный идентификатор, создаваемый на действие. Не нужно пользователя просить отправить повторно в интерфейсе, это некрасиво, лучше сообщить во float окошке что возникли ошибки и идет повторная отправка, со статистикой, 'сколько попыток' и кнопка 'прекратить'. Мало того, клиент должен различать логические ошибки (например в коде была ошибка и старая версия фронтэнда пытается отправить уже неверный формат сообщения бакэнду, и он ругается на это, повторять действие не требуется, а вот предложить способы решения - да)
Проблемы с несовместимостью версий вообще классика, когда разработчику лень поддерживать на время миграции сразу две (это реально не просто бывает) но могут вылезти очень внезапно, и сообщить об этом в логах очень важно, особенно когда часто практикуется обновления на живую.
По этой причине, систему логирования ошибок с фронтэнда лучше разнести подальше от основного кода и логики бакэнда (вплоть до другого физического железа), туда же можно кидать ошибки и бакэнда
Простой