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

UserCommands are called on Update types with same name (PollCommand on poll Update etc.) #1312

Open
TiiFuchs opened this issue Apr 11, 2022 · 4 comments
Labels

Comments

@TiiFuchs
Copy link
Member

When defining a PollCommand extends UserCommand and added via addCommandClass(),

this classes execute method is also called, when an Update of type Poll comes in.

I think on Update Types, it should check, if the registered class is extending SystemCommand.

@TiiFuchs TiiFuchs added the bug label Apr 11, 2022
@noplanman
Copy link
Member

@TiiFuchs This is because of the way the commands were implemented way back when.

<UpdateType>Command classes get called when an Update comes in.

From what I recall, if you leave the $name blank, it doesn't get called. Or maybe that was only the case when a user executes it 🤔

There are a bunch of issues open regarding the current command system, and this particular scenario has come up before I think.

@TiiFuchs
Copy link
Member Author

We should think about a way to solve this. I think the current behaviour as described can get pretty frustrating.

@TiiFuchs
Copy link
Member Author

Any idea?

I don't like that different Update Types call something like ...Command... It is not a Command, it should not be called that way.
Maybe we can change this to ...Update or something... So when there is a new Update with type poll, it looks for a PollUpdate class, if it is an inline_query it looks for InlineQueryUpdate etc.

What do you think, @noplanman

@noplanman
Copy link
Member

I like the idea of having dedicated <Type>Update classes to cleanly separate user commands and updates coming in from Telegram.

There are a few issues labled "code design" which are about this too.

I think we can hugely improve the whole flow of a request cycle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants