Механизм анализа ошибок

Смотреть видео - Механизм обработки и анализа ошибок    https://rutube.ru/video/private/38eac8da1f2dd7e6d21a729797210384/?p=iXpbet7GtHvtRlM6G5KI1g

В платформе есть надстройка для более плотного анализа ошибок. 

При появлении ошибки она логируется в as_trace, при этом производится анализ ошибки для отнесения ее к категории и определении ее критичности (в отдельной таблице as_errors). 

На базе этого строится отчет (таблица errors), который дает понимание какие ошибки, как часто происходят, т.е. есть возможность быстро оценить текущую ситуацию по ошибкам. 

Вверху выводится статистика по кол-ву ошибок за периоды. 

Далее идут фильтры таблицы. Число у каждого фильтра - это количество ошибок, связанных с фильтром за неделю. (В примере ошибка truncated была 1 раз за неделю). 

Тип ошибки - это либо SQL ошибка, либо JS, либо что-то другое (системное или что не подпало под паттерны ошибок SQL, JS). 

Категория - это основной элемент типизации ошибок. На базе него определяется критичность ошибки.  Анализ категории ведется на основе строковых паттернов в описании ошибки.

Какие есть категории ошибок (список постепенно дополняется): 

• truncated - обрезана строка (значение не вместилось в переменную строки). Необходимо увеличить размерность строки или предварительно обрезать данные.
• nullRef - в ядре выдало ошибку, что идет обращение к объекту NULL
• invalidJSON - попытка обработки невалидной строки JSON
• email- проблемы с отправкой email
• convertType - проблема с конвертацией типов в SQL (например из строки в число. Используйте try_cast для безопасного приведения)
• ambiguousName - в запросе используется имя, которое есть в разных таблицах (надо указать префикс таблицы, напр. t1.id)
• saveSP - ошибка при редактировании хранимой процедуры (поменял процедуру и нажал Сохранить)
• doubtTransaction - транзакция не была выполнена (встречается в CRON иногда)
• unableDTC - Проблема с выполнением транзакций. Детали - https://stackoverflow.com/questions/15410918/msdtc-exception
• timeout - операция слишком долго выполнялась и была отменена по таймауту.
• invalidCol - неверно указана колонка таблицы где-то в SQL.
• noSelect - платформа ожидает выходного SELECT из процедуры, а его нет. 
• deadlock - зафиксировал дедлок (блокировка ресурсов). Как решать - https://falconspace.ru/list/sqlserver/sql-deadlock-problem---318
• badSubquery - подзапрос вернул более 1 значения (обычно решение - использовать in вместо =, и необходимо проверить должен ли в принципе подзапрос возвращать более 1 значения по смыслу).
• badInsertFK - ошибка вставки записи в таблицу из-за ограничений внешних ключей. Часто ошибка в том, что значение по умолчанию "0" вставляют в поле внешнего ключа (а там либо NULL либо число>0 - решение nullif(value,0)).
• badInsertFieldCount - при вставке insert число полей отличается (проверьте соответствие полей insert и values). 
• invalidURI - некорректный URL адрес. Встречается при неверном адресе при загрузке файла с удаленного хоста. 
• badDeleteFK - не дает удалить запись из-за внешнего ключа. Лучше всего в явном виде обработать все связанные с нашей удаляемой записью объекты. 
• 403 - отказ в доступе. Встречается при неверном токене в исходящем API. 
• sqlInvalidLength - параметр Length в SQL функции LEFT или SUBSTRING функциях неверно задан (например, отрицательный). 
• noSignalR - проблема с подключением SignalR. Встречается на лендингах, лечится добавлением необходимых скриптов в лендинг (посмотреть можно по аналогии с загрузкой стандартной страницы falcon).  
• jsUndefinedRef - в JS идет обращение к полю Undefined или null объекта. 
• invalidName - неверно указан объект БД в хранимых процедурах (например, имя таблицы). 
• badFilePath - платформа не может найти путь на локальном диске к некоторому файлу. Проверьте, что файл, папка существует, и наличие спецсимволов в имени файла.