😭 Knex JS ломает logger
Knex – одна из самых известных библиотек для работы со SQL в NodeJS. И как полагается, подобного рода библиотеки могут принимать на вход внешний логгер.
НО вместо того, чтобы просто вызывать функции логгера, он переприсвает все его методы в свой класс (фото 1)...
Догадались в чем может быть проблема? Ответ через 3... 2... 1...
А проблема в том, что если ваш логгер под собой использует "this" без байндинга к инстансу (что не является обязательным), то теперь его "this" будет ссылаться на класс внутреннего логгера Knex...
В последних проектах я часто использую логгер Pino и внутри его логики используется "this" без байдинга и это приводит к крашу приложения
Чтобы все заработало приходится использовать мерзкий хак (фото 2)
Чему это нас учит?
"this" очень коварная штука и, конечно, мне хочется сказать "просто перестаньте использовать классовую нотацию" (потому что я ее уже давно не использую), но в реальности прошу вас хотябы не переприсвайте методы другого (особенно неподконтрольного) "объекта"
Мощной вам прокачки 💪
Knex – одна из самых известных библиотек для работы со SQL в NodeJS. И как полагается, подобного рода библиотеки могут принимать на вход внешний логгер.
НО вместо того, чтобы просто вызывать функции логгера, он переприсвает все его методы в свой класс (фото 1)...
Догадались в чем может быть проблема? Ответ через 3... 2... 1...
А проблема в том, что если ваш логгер под собой использует "this" без байндинга к инстансу (что не является обязательным), то теперь его "this" будет ссылаться на класс внутреннего логгера Knex...
В последних проектах я часто использую логгер Pino и внутри его логики используется "this" без байдинга и это приводит к крашу приложения
Чтобы все заработало приходится использовать мерзкий хак (фото 2)
Чему это нас учит?
"this" очень коварная штука и, конечно, мне хочется сказать "просто перестаньте использовать классовую нотацию" (потому что я ее уже давно не использую), но в реальности прошу вас хотябы не переприсвайте методы другого (особенно неподконтрольного) "объекта"
Мощной вам прокачки 💪
Комментарии: 13
4
🦾
Б
Очередная проблема с axios, по факту я нашел еще несколько авторы очевидно не справляются с правками в своей либе (и покрытием тестов), есть мысли вообще слезать на свой клиент на основе чистой ноды.
Так вот проблема в том что таймауты перестали работать корректно после замены агента на чистый нодовской (напомню мы заменяем агент т.к. добавляем туда метрики по вермени).
Самое забавное что по идее и так должен братся нодовский http клиент, это можно посмотреть в репе либы https://github.com/axios/axios/blob/199c8aab64c45532389f3e56a913017a54803dfe/lib/adapters/http.js#L189 и подключаемые либы сверху. Поэтому для меня оказалось странной проблема нарушения некоторых поведений.
Сейчас еще раз пересмотрев код axios в репе проекта, я заметил то на что не обращал внимания раньше, а именно на config.maxRedirects, в случае >0 который берет http(s)Follow. Стоит отметить что по умолчанию config.maxRedirects = 5, поэтому мы всегда попадаем какраз на этот агент. Раньше я думал что это просто небольшой фикс над http либой, но оказалось я ошибался. Работа timeout не реализованна в должной мере в axios. Она попросту работает только на либе follow-redirects, и никто не удосужился покрыть тестами нодовский клиент. Т.е. парни даже не проверили что будет если выставить maxRedirects = 0. В то время люди писавшие либу которая должна была решать только проблему follow redirect еще и улучшили работу логики таймаутов (тем самым изменив ее), и так сложилось что разработчики axios сами того не зная пользовались этой фишкой...
Исправленная логика таймаутов:
https://github.com/follow-redirects/follow-redirects/blob/main/index.js#L148
Так вот проблема в том что таймауты перестали работать корректно после замены агента на чистый нодовской (напомню мы заменяем агент т.к. добавляем туда метрики по вермени).
Самое забавное что по идее и так должен братся нодовский http клиент, это можно посмотреть в репе либы https://github.com/axios/axios/blob/199c8aab64c45532389f3e56a913017a54803dfe/lib/adapters/http.js#L189 и подключаемые либы сверху. Поэтому для меня оказалось странной проблема нарушения некоторых поведений.
Сейчас еще раз пересмотрев код axios в репе проекта, я заметил то на что не обращал внимания раньше, а именно на config.maxRedirects, в случае >0 который берет http(s)Follow. Стоит отметить что по умолчанию config.maxRedirects = 5, поэтому мы всегда попадаем какраз на этот агент. Раньше я думал что это просто небольшой фикс над http либой, но оказалось я ошибался. Работа timeout не реализованна в должной мере в axios. Она попросту работает только на либе follow-redirects, и никто не удосужился покрыть тестами нодовский клиент. Т.е. парни даже не проверили что будет если выставить maxRedirects = 0. В то время люди писавшие либу которая должна была решать только проблему follow redirect еще и улучшили работу логики таймаутов (тем самым изменив ее), и так сложилось что разработчики axios сами того не зная пользовались этой фишкой...
Исправленная логика таймаутов:
https://github.com/follow-redirects/follow-redirects/blob/main/index.js#L148