Версия: nestjs-max — 0.2.1
Ожидаемое поведение
Опция middlewaresAfter в MaxModuleOptions по названию и смыслу должна выполнять middleware после того, как апдейт прошёл через зарегистрированные листенеры (@Maxupdate, @MaxCommand, @maxaction и т.д.) — например для логирования, метрик, очистки контекста.
Фактическое поведение
Middleware из middlewaresAfter не выполняется в типичном сценарии, когда апдейт обрабатывается одним из листенеров (команда/колбэк/и т.д.).
Почему так может происходить (гипотеза)
В MaxExplorerService.onModuleInit() порядок такой:
bot.use(...middlewaresBefore)
explore() — регистрация @MaxMiddleware и затем всех листенеров из @Maxupdate
bot.use(...middlewaresAfter)
В max-io цепочка строится через Composer.compose / concat: следующий слой вызывается только когда предыдущий вызывает next(). Если слой с листенерами обрабатывает апдейт и не пробрасывает next() дальше по цепочке, то middleware, зарегистрированное после этой ветки (как middlewaresAfter), может никогда не получить управление.
В результате middlewaresAfter фактически срабатывает только в случаях, когда апдейт «пролетает» через листенеры без полноценной обработки (или при явном вызове next()), что не совпадает с ожиданием «после каждого обработанного апдейта».
Шаги воспроизведения
В MaxModule.forRoot / forRootAsync передать в useFactory что-то вроде:
middlewaresAfter: [
async (ctx, next) => {
console.log('after middleware');
await next();
},
],
Отправить боту сообщение, которое обрабатывается методом с @MaxCommand / @maxaction в @Maxupdate.
Убедиться, что 'after middleware' не появляется в логах (или ставить breakpoint).
Версия: nestjs-max — 0.2.1
Ожидаемое поведение
Опция middlewaresAfter в MaxModuleOptions по названию и смыслу должна выполнять middleware после того, как апдейт прошёл через зарегистрированные листенеры (@Maxupdate, @MaxCommand, @maxaction и т.д.) — например для логирования, метрик, очистки контекста.
Фактическое поведение
Middleware из middlewaresAfter не выполняется в типичном сценарии, когда апдейт обрабатывается одним из листенеров (команда/колбэк/и т.д.).
Почему так может происходить (гипотеза)
В MaxExplorerService.onModuleInit() порядок такой:
bot.use(...middlewaresBefore)
explore() — регистрация @MaxMiddleware и затем всех листенеров из @Maxupdate
bot.use(...middlewaresAfter)
В max-io цепочка строится через Composer.compose / concat: следующий слой вызывается только когда предыдущий вызывает next(). Если слой с листенерами обрабатывает апдейт и не пробрасывает next() дальше по цепочке, то middleware, зарегистрированное после этой ветки (как middlewaresAfter), может никогда не получить управление.
В результате middlewaresAfter фактически срабатывает только в случаях, когда апдейт «пролетает» через листенеры без полноценной обработки (или при явном вызове next()), что не совпадает с ожиданием «после каждого обработанного апдейта».
Шаги воспроизведения
В MaxModule.forRoot / forRootAsync передать в useFactory что-то вроде:
middlewaresAfter: [
async (ctx, next) => {
console.log('after middleware');
await next();
},
],
Отправить боту сообщение, которое обрабатывается методом с @MaxCommand / @maxaction в @Maxupdate.
Убедиться, что 'after middleware' не появляется в логах (или ставить breakpoint).