non ti fidare di allow_sending_without_reply=False

[zeroone2numeral2]

allow_sending_without_reply=False non è affidabile, perchè se si elimina il messaggio da Android, l'api non saprà che è stato eliminato perchè il revoke avviene solo per la copia dell'utente del messaggio. Descrizione bug:

Hello, I would like to report an issue with how the Android app behaves when the user deletes a message in a conversation with a bot.

Right now, the request to delete the message will not ask the API to revoke it for the other party too. Which is usually not a big deal - but this might result in an unwanted behavior with the bot API, particularly, with the 'allow_sending_without_reply' parameter most of the send* methods offer.

Consider the following scenario: I've developed a bot using the bot API that allows user to request some items, and an individual item (link, photo, video, document...) can be requested multiple times. The bot keeps track of these requests, and when a specific request (eg. uploading a document) has already been answered in the past, the bot will simply reply to the previously-sent message telling the user "hey, you've already asked me for this, look at this message ^". Now, that's when the 'allow_sending_without_reply' comes into play. Setting this parameter to 'false' will make the API return an error if the message we're trying to reply to was, for example, deleted from the chat. If this error is returned, the bot knows the message it's trying to reply to was deleted, and thus the content the user asked for must be re-uploaded.

The problem is: if the user deletes a message from the bot's chat using the Android app, the API will not tell the bot account that the message was deleted. This means that the bot API will not be able to update its cache and remove the message from the message that can be replied to. And this means that a message sent with the 'allow_sending_without_reply' to 'false' will be sent regadrless - even if the replied-to message in the user's chat no longer exist! The bot will not be able to know that the user won't see that message as a reply.

More context: A conversation in tdlib's chat regarding a possibile bug in the bot API, that was actually caused by different behaviors when deleting a message from different clients: https://t.me/tdlibchat/68596 - the behavior, in fact, has already been patched on the desktop app (for different reasons, but still, now Android and Desktop behave differently): https://github.com/telegramdesktop/tdesktop/issues/17033

Now, I could change how the bot behaves so I don't have to rely on the 'allow_sending_without_reply' parameter. But this behavior in the Android client results in unexpected behavior from bots - which might be even harder to debug considering that tdesktop behaves in such a way that will allow the bot API to operate (and raise the correct exception) as described in its documentation

Discussione tgbetachat: https://t.me/tgbetachat/1742764

Hello, I would like to report a behavior in the android app that caused me a quite big headache while developing a bot using the bot API

So in the bot API, almost every method that allows the bot to send something (text messages, photos, etc) comes with a parameter called allow_sending_without_reply. This allows developers to decide whether a send* request should fail if the message we're replying to is not found (eg. it has been deleted from the chat). This always worked perfectly, and I was using it to reply to old messages sent in the user's private chat if the bot was asked to send something that was already sent in the past - and having the sendMessage request fail if eg. the user deleted the old message would allow me to re-send the content the user asked for

Yesterday I was testing this with a bot and apparently the api was ignoring the allow_sending_without_reply parameter, because the bot's messages were being sent even if the replied-to message was deleted by me. I've spent a lot of time trying to figure out why the production bot was failing and the test bot was not, both running the same code.

Apparently the reason is that the message was deleted from the android client, and the android client does not ask the API to delete the message for both parties if you delete that message in a bot chat. And since the message was not revoked for both parties, the bot API doesn't know the message is no longer available in the user's chat, and this means that the API will not be able to raise an exception when you reply to a message that no longer effectively exist in the user's chat, thus resulting in an unwanted behavior from the bot!

This was reported on tdesktop some time ago and has been fixed: https://github.com/telegramdesktop/tdesktop/issues/17033

Messaggi Fela:

Fela, [21/11/2023 16:51]
Cmq sto vedendo un attimo

Fela, [21/11/2023 16:51]
Ti faccio sapere

riccardo, [21/11/2023 17:07]
Grazie mille!

riccardo, [21/11/2023 17:10]
Più che altro è che appunto il mio problema è che io credo che sia successa una cosa, mentre per l'utente ne è successa un'altra, e non ho modo di saperlo. A leggere da tdlib chat e su telegram-bot-api sembra che comunque quel parametro sia da considerarsi affidabile - e sarebbe un peccato non lo fosse. Il fatto è che in questo caso, non lo è per colpa di come l'api/tdlib gestiscono la propria cache, ma per come si comporta il client

Fela, [21/11/2023 17:11]
Sono con Alexey e dice che il behavior delle app mobile e intended, è quello desktop a non esserlo

riccardo, [21/11/2023 17:13]
ma che dice dello scenario che ho descritto? perchè il mio bot continua a dire all'utente: "mi hai già chiesto questa cosa, ed io ti ho risposto qui ^", credendo di rispondere ad un messaggio che in realtà non c'è (ma per la cache di tdlib/bot api invece c'è ancora - e non ci sarebbe se il client avesse chiesto il revoke anche per il bot!

riccardo, [21/11/2023 17:14]
non so se mi spiego

riccardo, [21/11/2023 17:14]
cioè ci tengo a sta cosa perchè sul serio ci ho perso due ore oggi ahah

Fela, [21/11/2023 17:14]
Dice in generale di non basare la UX del bot su quella flag perché il bot potrebbe perdere accesso a quel messaggio in qualsiasi momento senza che necessariamente sia perso anche per l’utente

riccardo, [21/11/2023 17:14]
ok, capisco

riccardo, [21/11/2023 17:15]
per me non è un problema cambiare come il bot funziona, alla fine

Fela, [21/11/2023 17:16]
Penso che la decisione di cancellare il messaggio solo per se stessi sia stata fatta perché di fatto non c'è modo di forzare il bot a cancellare il messaggio

Fela, [21/11/2023 17:17]
Ma potrei sbagliarmi, qua parlano tutti solo in russo e mi perdo un sacco di passaggi 🥴

riccardo, [21/11/2023 17:19]
si infatti sono d'accordo che abbia senso. l'intento è quello di fare in modo che l'utente non venga spinto a credere che eliminare il messaggio lo renderà indispoonibile anche a chi gestisce il bot, visto che non è vero. Però è una cosa che gestisci a livello di UX, no? Dici all'utente che il messaggio verrà rimosso solo per loro (come fa tdesktop), però invii comunque la richiesta di revoke

Fela, [21/11/2023 17:20]
Sì potrebbe avere un senso

Fela, [21/11/2023 17:20]
Ma dubito che a questo punto venga di nuovo cambiata, perché appunto non puoi fare affidamento sul fatto che un messaggio esista o meno

[zeroone2numeral2]

Dove va sistemato:

• [x] generazione link d'invito
• [x] /comment (fa controllo su presenza post canale nel gruppo di discussione - non dovrebbe essere un problema perchè il problema riscontrato da noi riguarda solo le chat private, però potrebbe rimanere inaffidabilità descritta da Fela)

[zeroone2numeral2]

/comment non è un problema perchè si risponde ad un messaggio del canale nel gruppo di discussione, quindi dovrebbe essere abbastanza affidabile