progress bar
Follow-up for TODO: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot/-/blob/6582e2df9b291fa91fbfdcc214dda518b81d8009/OnionSproutsBot/files.py#L28
The progress bar should show the status of the file downloads (and subsequent uploads) to Telegram's servers, before they are served to the user. Even if that case scenario in the real-world will only occur rarely, as all files that have been already uploaded to Telegram's servers have been cached, there's a few cases where this could be useful:
- If the bot has a lot of activity, either because of a DoS or an "internet hug of death", it's good to inform the user that their request is being processed. That way, they won't keep repeating their requests over and over again, thus making the problem worse. This actually happened; Our bot made many RPC calls and triggered a ratelimit, which delayed responses a lot, especially as the requests kept increasing exponentially. Users ended up getting responses to their queries after hours. That must've been excessively frustrating. Especially if you were one of the users that ended up spamming the buttons repeatedly, waiting for some sort of a reaction. Some people actually did that, and got responses at completely random times, up to 6 hours later. It got annoying enough to the point where they blocked it. The underlying problem here was the lack of transparency. If transparency had been there from the start, the problem would have likely been much less worse.
- If we ever find ourselves in some sort of a catastrophic situation, some additional visual feedback would make pinpointing the cause of that situation much easier (Is Tor's underlying infrastructure experiencing an outage or are we being blocked from uploading things for some reason and not getting clear feedback from the API about it?). It would also be helpful if a user could inform us of the part that they got stuck on directly.
- Another example would be local debugging and development, especially if a developer only has access to a slow Internet connection. However, locally, this can get very confusing: For example, the library
aiohttp
has a default timeout of 5 minutes. If I simulate a DoS attack by flooding the bot with a lot of requests, artificially limit its available bandwidth or just happen to have a slow Internet connection, I would not be able to tell why a request failed. With a progress bar, inferring the root cause ("Did we hit the timeout?", "Did the download never start to begin with?", "Are uploads to Telegram's servers extremely slow/throttled?", etc.) would be much, much easier. Being able to measure the performance of the bot in that context would also be useful when optimizing its performance.
Being a perfectionist can't possibly hurt.