И вот ты получаешь полную информацию о проблеме. Допустим, это ошибка ECC, которая привела к MCE на мастере в кластере БД и вызвала оборванное соединение в середине транзакции в приложении, которое ведёт финансовый лог операций для процессора карточек. А retry там нет по финансовым причинам (чтобы избежать double writing).

Отчёт про ошибку ECC (номер банка памяти, номер сервера, описание сервера, который это заметил (через netconsole, например) - 200кб.
Супервизор базы данных, который это нашёл - 300кб. (данные супервизора, аудит-трейл получения данных и т.д.)
Приложение - ещё 200кб (потому что трейс глубокий и есть контекст)
Это приложение вернуло ошибку фрод-системе (лог ещё 1Мб, потому что много обстоятельств).
Это приложение вернуло ошибку в код обработки транзации. (+500кб)
Это приложение вернуло ошибку банку-процессору (+2Мб, потому что чужая система и нам нужны полные данные)
Это приложение вернуло ошибку терминалу, к которому ты приложил карточку.

Терминал должен дать тебе квиток с ошибкой. Нам написно Rejected и ID транзакции.

Надо ли в терминале печатать эти 5 мегабайтов ошибки, из которой ты узнаешь, в какой планке памяти на каком сервере битая память.

Я утрирую, но идея именно та. Глубина трейса должна быть ограничена, иначе обработки ошибок не будет.