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

Duplicate Class Declaration Error with Commands Matching Message Types (e.g., LocationCommand) #1481

Open
VoDmAl opened this issue Oct 17, 2024 · 0 comments
Labels

Comments

@VoDmAl
Copy link

VoDmAl commented Oct 17, 2024

🐞 Bug Report

Required Information

? !
Operating system Debian 10
PHP Telegram Bot version 0.83.0
PHP version 8.2.20
MySQL version none
Update Method Webhook
Self-signed certificate no
RAW update (if available) {...}

Summary

When implementing custom commands that share names with message types (e.g., LocationCommand and PollCommand), the fatal error appears "Cannot declare class ... because the name is already in use" error when processing messages of those types (e.g., when receiving a location or poll message). This appears to be due to different approaches in how the bot loads commands and handles message types, leading to duplicate class declarations.

Current behaviour

Custom commands like LocationCommand and PollCommand are created to handle /location and /poll commands.
These commands are properly registered and loaded by the bot.
When the bot receives a text "/command" everything works correct.
When the bot receives a location or poll message (as message content, not as a command), it attempts to process it by converting the message type to a command name (e.g., location becomes Location).
The bot checks if a command class exists for that message type using class_exists($class_name) without setting the $autoload parameter to false.
This triggers the autoloader, which tries to load the class again, resulting in a duplicate class declaration error:

Compile Error: Cannot declare class Longman\TelegramBot\Commands\UserCommands\LocationCommand, because the name is already in use

How to reproduce

  1. Implement commands named LocationCommand and PollCommand to handle /location and /poll commands.

  2. Send a Message of the Conflicting Type: Send a location or poll message to the bot (not as a command, but as regular message content).

  3. Observe the Error: The bot throws a compile error about the class already being declared.

Expected behaviour

The bot should process location or poll messages without errors.
The existing LocationCommand or PollCommand should handle /location or /poll commands when they are explicitly invoked.
No duplicate class declaration errors should occur when processing messages that match command names.

Additional details

  1. Different Loading Approaches:
    The bot loads commands from the specified directory recursively, creating a mapping of command names from the command property of each class to the class itself.
    When processing certain message types, the bot attempts to map the message type to a command by converting the message type string (e.g., location) to a class name (e.g., Location).

  2. Issue with class_exists in getCommandClassName:
    In Telegram.php, the bot uses class_exists($class_name) without the $autoload parameter set to false.
    This causes the autoloader to attempt to load the class again, even if it's already been loaded, leading to a duplicate declaration error.

  3. Possible solutions
    3.1. Modify the class_exists Check:Change the class_exists function in Telegram.php to prevent autoloading
    3.2. Adjust Command Name Resolution: Modify how the bot maps message types to command names to avoid conflicts with existing command classes. For instance, differentiate between commands and message types by using a different naming convention or adding a prefix/suffix.

Thank you. If any additional information is needed, please let me know.

@VoDmAl VoDmAl added the bug label Oct 17, 2024
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

1 participant