You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How is the developer supposed to access the response for asynchronous requests? When calling $api->getMe() it returns an (non-populated/empty) Telegram\Bot\Objects\User object. I've followed the call-stack and cannot find a proper way to access the response promise:
#0: \Telegram\Bot\Api::getMe() (through \Telegram\Bot\Methods\Get)
#1: \Telegram\Bot\Api::get() (through \Telegram\Bot\Traits\Http) // <-- This call should preserve the promise!
#2: \Telegram\Bot\Api::sendRequest() (through \Telegram\Bot\Traits\Http)
#3: \Telegram\Bot\TelegramClient::sendRequest()
#4: \Telegram\Bot\TelegramClient::getResponse()
#5: \Telegram\Bot\TelegramResponse::__construct():
The problem is, that TelegramResponse seems to discard the promise once and for all in its constructor.
TelegramResponse.php:
// $response gets dismissed if it is an instanceof PromiseInterface!publicfunction__construct(TelegramRequest$request, $response)
{
if ($response instanceof ResponseInterface) {
// [Removed for readability]
} elseif ($response instanceof PromiseInterface) {
$this->httpStatusCode = null;
} else {
// [Removed for readability]
}
$this->request = $request;
$this->endPoint = (string) $request->getEndpoint();
}
I just found this library and wanted to check if it proves useful for migrating an existing bot. I thought this would be a perfect choice since it relies on GuzzleHttp (which my current implementation also does) and supports asynchronous requests (which my current implementation also relies on).
So my question is basically: Am I missing something?, and if not: Is this feature supposed to be implemented in a future release? What I would expect on how to use the library is this:
// Create required instances$api = new \Telegram\Bot\Api($myToken = '...', $async = true, $clientThatUsesCustomHandler);
$api
->getMe()
->then(function (\Telegram\Bot\Objects\User$user) {
// Do something with $user...echo"I am executed asynchronously";
});
// Enter main loopwhile(true) {
// Application logic goes here...// Required by guzzle to process pending requests...$guzzleHandlerThatIsUsedByMyClient->tick();
\GuzzleHttp\Promise\queue()->run();
// Probably sleep for some timeusleep(0.025 * 1E6);
}
Ideally the \Telegram\Bot\HttpClients\GuzzleHttpClient would provide a tick() method on its own so that it can be used for integration in the main application event loop. This would render the need to create a cutom handler unnecessary when using the default implementation.
The text was updated successfully, but these errors were encountered:
👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.
How is the developer supposed to access the response for asynchronous requests? When calling
$api->getMe()
it returns an (non-populated/empty)Telegram\Bot\Objects\User
object. I've followed the call-stack and cannot find a proper way to access the response promise:The problem is, that
TelegramResponse
seems to discard the promise once and for all in its constructor.TelegramResponse.php:
I just found this library and wanted to check if it proves useful for migrating an existing bot. I thought this would be a perfect choice since it relies on GuzzleHttp (which my current implementation also does) and supports asynchronous requests (which my current implementation also relies on).
So my question is basically: Am I missing something?, and if not: Is this feature supposed to be implemented in a future release? What I would expect on how to use the library is this:
Ideally the
\Telegram\Bot\HttpClients\GuzzleHttpClient
would provide atick()
method on its own so that it can be used for integration in the main application event loop. This would render the need to create a cutom handler unnecessary when using the default implementation.The text was updated successfully, but these errors were encountered: