-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bot webhook not waiting for session middleware to finish #5
Comments
You should await your Another observation is that you should move initBot outside the request handler as an optimisation; you'd want it to happen when the Lambda warms up instead of on every request. initBot doesn't even need to be a function call. Its contents can just live outside. Is there any reason you chose to do it this way? It's still a little bit weird that it kills the Lambda before updating store is logged; I would have expected it to some times update store before |
I just made the changes you suggested. First of all thank you for letting me now about the initBot function. I already fixed that and I also added await to the wizardsStage.hears(UserInteractionConstants.CURRENCY_QUERY_ACTION, async ctx => {
console.log(`Inside ${UserInteractionConstants.CURRENCY_QUERY_ACTION}`);
const customState: BotState = (ctx as any).customState
if (customState.isAdmin) {
ctx.reply('Consultar divisas', CurrencyQueryKeyboard)
} else if (customState.isSalesman) {
await ctx.scene.enter(SceneIDS.QUERY_CURRENCIES_SALESMAN)
}
}) As you can see I have a log inside this function just to know when this logic is executed I also have a log when the webhook handle function finished export const message = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
try {
const body = JSON.parse(event.body!)
console.log(body)
await webhookHandle(body)
console.log('Finished webhook handle')
return { body: JSON.stringify({ message: 'Ok' }), statusCode: 200 }
} catch (error) {
return { body: JSON.stringify({ message: 'Error' }), statusCode: 500 }
}
} However take a look at the AWS Cloudwatch logs when I execute this action
I don´t know why, but it is like if webhookHandle function is not awaiting for anything. It returns even before that session middleware its doing its job |
I am thinking about solving this with the sleep workaround but I want to do it only when it is necessary. Is there any way for me to know when the session middleware is executed to add the 150 ms only in that situation? Any idea? |
Yeah, this is the root problem. It's still a missing await somewhere, but we're not able to nail where it is. Do you call Worst case, are you open to privately sharing the codebase, if you want me to take a look at other potential issues? |
Yes, I have no problem on sharing the codebase with you, just let me know how could I proceed. Thanks in advance |
Please reach out on Telegram, https://t.me/MKRhere |
Any update about this? |
I am migrating a long polling bot to webhook using AWS Lambda. I added '@telegraf/session/mongodb' package to store sesion info in my mongodb database.
After I finished setting up my bot everything works fine but the wizard scenes. I started debuguing and it looks like the problem is related to the session middleware. Let me show you my AWS Cloudwatch logs:
As you can see it doesn't print the following message:
That's why my code never gets into the wizard scenes. Let me show you my code because maybe I am missing something
webhookHandle function:
My problem basically is that I don´t know why but the webhook handle function is not waiting for the bot to completely handle the update
I added this to my code and everything works perfectly now:
I added this above the return statement inside the handler function and everything worked now. But it is not an elegant solution and I added 150 ms of billing time to every request, so the question is:
Why do you think it is not waiting for the bot to handle the update?
Let me show you my initBot function
Now inside initCurrenciesRoute function (this is just an example of how it is implemented all routes for each entity)
The text was updated successfully, but these errors were encountered: