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

Fixed response handlers for 'me', 'c', and related commands #3204

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

whyXVI
Copy link

@whyXVI whyXVI commented Jan 1, 2025

Resolved issue with handlers not being invoked post-query, ensuring proper response processing
Added proxy support with comments to aid users in quicker onboarding

Resolve issues where handlers were not invoked after sending queries, enabling proper response processing
@levlam
Copy link
Contributor

levlam commented Jan 1, 2025

The proposed changes contains multiple issues and aren't going to be merged.

It's a bad idea to continuously call receive with 0 timeout. This guarantees nothing and uses 100% CPU in the meanwhile. TDLib's interface is asynchronous and is supposed to be utilized as such.

only_current_query usage will lead to multiple updates missed and the app having invalid states. All updates must be processed as described at https://core.telegram.org/tdlib/getting-started.

getChat never needs to be called to get information about achat by apps that correctly handle updates.

There are also multiple issues with code formatting, which should be done automatically using clang-format. and naming conventions.

@whyXVI
Copy link
Author

whyXVI commented Jan 1, 2025

Thank you for your guidance! I noticed that [u] represents receiving all message updates. Previously, my messages flooded the information returned by certain commands. I want to address this issue.

Would it be a good idea to remove the handler output in process_update() when receiving messages? (Lines :224-:225, currently only updateNewMessage callbacks produce output.)
Alternatively, should we introduce an additional action to differentiate from 'u' and let process_response continuously process until the first response with request_id != 0 if any?

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

Successfully merging this pull request may close these issues.

2 participants