Skip to content
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

Wizard CB Query Handling - First Update #1896

Open
MascheroniNatan opened this issue Oct 24, 2023 · 1 comment
Open

Wizard CB Query Handling - First Update #1896

MascheroniNatan opened this issue Oct 24, 2023 · 1 comment
Labels
as-designed-not-as-expected Works as designed, not as expected

Comments

@MascheroniNatan
Copy link

MascheroniNatan commented Oct 24, 2023

Context

This bug is related to Callback Query handling entering a Wizard Scene. When the bot enters a wizard scene the first update cached by the scene itself is the CB Query. So if there is a matching action there it will be executed.

Expected Behavior

The bot should handle the CB Query and forget it.

Current Behavior

The bot handles it twice.

Workaround

Change the CB to a different text.

@MKRhere
Copy link
Member

MKRhere commented Oct 24, 2023

This happens because when an update enters a wizard, it calls its parent, base scene's handler. This is ostensibly to cause wizard.enter to run, but it runs any matching middleware attached directly to the wizard scene. If none is found, it drops down to wizard mode and runs the step 0.

const wizard = new Wizard("wizarudo", [ step0, step1 ]);
wizard.on("callback_query", ctx => ctx.reply("AHA, I ran first"));

bot.on("callback_query", ctx => ctx.scene.enter("wizarudo"));

This is caused by

return Composer.compose([this.enterHandler, this.middleware()])
trying to call the wizard's middleware.

WizardScene#enterMiddleware could be modified to call only WizardScene#enter and steps[0] in that order, but this would be a breaking change. I'd like more comments on this issue before I can "fix" it, and be sure nobody is relying on this behaviour.

Changing it so could also be unexpected behaviour, because when a user is in a wizard scene, any update will first run through the wizard's middleware (this is anything attached directly to the wizard) before it runs the current step. So probably a documentation issue more than a fix needed. Still, leaving this open for some time to accept comments.

@MKRhere MKRhere added the as-designed-not-as-expected Works as designed, not as expected label Oct 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
as-designed-not-as-expected Works as designed, not as expected
Projects
None yet
Development

No branches or pull requests

2 participants