Sometimes when users request a big image that bot needs to process to resize it, for example, it may take too much time to finish that processing. Telegram gives up on the inline query request when bot doesn't respond within some time N. The value of N isn't known to me yet, but I think it's either documented or easily discoverable with some experimentation via thread::sleep in the inline query handler.
The behavior we have today is that bot just never responds to the user and the user thinks as if bot was hung. The bot, though eventually finishes the processing of the inline query in background, and tries to send an inline query response back to telegram. However, telegram rejects the response because it already gave up on the inline query request.
This is a really shitty behavior that can lead to potential user loss, because users think as if bot is hung, and non-working, so they would never use it again.
Summary
The bot needs to send at least some response to the user. In case it can't process the media in time the bot needs to stop waiting for processing of the media and yield back to the user with the error message with some friendly text like "It took too much time to process your request. Try again". The try again part is important. It's very likely that the second time the user requests the same media they'll get a result back and rather quickly. This is because the processing of the media shouldn't get cancelled. It'll proceed in the background. So when the user requests the same media again it'll be likely that the media already was processed and cached, so they'll get a quick response from cache.
Implementation notes
I think this logic needs to be implemented inside of the inline query handler function itself. The place where it sends a request to posting service is the one to focus on. Use tokio::time::timeout function to implement the timeout for waiting on the posting service response.
Context
Sometimes when users request a big image that bot needs to process to resize it, for example, it may take too much time to finish that processing. Telegram gives up on the inline query request when bot doesn't respond within some time
N. The value ofNisn't known to me yet, but I think it's either documented or easily discoverable with some experimentation viathread::sleepin the inline query handler.The behavior we have today is that bot just never responds to the user and the user thinks as if bot was hung. The bot, though eventually finishes the processing of the inline query in background, and tries to send an inline query response back to telegram. However, telegram rejects the response because it already gave up on the inline query request.
This is a really shitty behavior that can lead to potential user loss, because users think as if bot is hung, and non-working, so they would never use it again.
Summary
The bot needs to send at least some response to the user. In case it can't process the media in time the bot needs to stop waiting for processing of the media and yield back to the user with the error message with some friendly text like "It took too much time to process your request. Try again". The
try againpart is important. It's very likely that the second time the user requests the same media they'll get a result back and rather quickly. This is because the processing of the media shouldn't get cancelled. It'll proceed in the background. So when the user requests the same media again it'll be likely that the media already was processed and cached, so they'll get a quick response from cache.Implementation notes
I think this logic needs to be implemented inside of the inline query handler function itself. The place where it sends a request to posting service is the one to focus on. Use
tokio::time::timeoutfunction to implement the timeout for waiting on the posting service response.