Дело в том, что для предотвращения лишних запросов за серверным кодом микрофронтов и экономии на парсинге строки в код, результаты работы этого загрузчика кэшируются в LRU-кэше.
И вот эта маленькая и безобидная стрелочная функция со всем своим богатым Closure сохраняется в памяти приложения практически на все время его жизни.
В приложениях могут быть сотни страниц, на которых используются десятки разных микрофронтов.
А в Tramvai есть модуль прогрева кэшей, который на старте сервера делает запросы к каждому роуту приложения.
Таким образом сразу после релиза, кэши прогреты, приложения работают быстрее, но и потребление памяти растет сразу при наличии утечки.
Интересно, что у нас есть тест на утечки памяти который недавно актуализировали - но такую комбинацию модулей и большого количества страниц и микрофронтов как у проблемного приложения мы вряд ли воспроизведем в этом тесте.
Также, не до конца понятно на каких уровнях надо чинить утечку.
С одной стороны не хочется трястись над каждым замыканием и бояться создавать новые функции (а как мы видим это и тулинг может сделать без нашего участия).
С другой стороны хочется предотвратить возможность выстрела в ногу, и исправить такие места как
createCache с ссылкой на commandLineExecutionContext.В общем есть о чем подумать, интересны ваши мысли и опыт исправления таких вещей.