visciang / telegram

Telegram library for the Elixir language
MIT License
204 stars 27 forks source link

sendPhoto silently does nothing? #137

Closed lawik closed 2 years ago

lawik commented 2 years ago

Hey

Playing around with a bot and trying to send a Photo, the multipart request just never completes. I get the log line before but never the one after.

visciang commented 2 years ago

Hi @lawik,

I've pushed branch ISSUE-137, it extend the example/example_bot.exs with a command to send you back a photo. Just tested right now and "it works on my machine"!

Could you play there and check again?

Start the bot from that branch:

~/Code/telegram ISSUE-137
❯ BOT_TOKEN=___YOUR_BOT_TOKEN___ ./example/example_bot.exs

then from a telegram client send to your bot the command /send_photo. You should get back the telegram logo without notification sound.

If you can pin the variables that give you the issue will be easier to backtrack the root cause.

visciang commented 2 years ago

Some constraints on photos are described here (max 10 MB, ...) https://core.telegram.org/bots/api#sendphoto Anyway, a HTTP request (multipart or not) should end soon or later, even more considering:

    @gun_config Application.compile_env(:telegram, :gun_config,
                  timeout: 60_000,
                  connect_timeout: 5_000,
                  certificates_verification: true)
lawik commented 2 years ago

Did some fun debugging. My images were slightly bigger, 211Kb and up. Not big by any means but bigger than 6.3Kb that you have for testing. So yours is just under 64Kb :)

I tried padding your image with 1Kb of nulls until a send failed.

I was okay sending 64745 bytes. I failed sending 65769 bytes.

lawik commented 2 years ago

So yes, your example works. No other image I have will :D

lawik commented 2 years ago

Oh, and it never returns. It idles for 30 seconds and then times out and retries.

visciang commented 2 years ago

Ahh! I would like to play with the tesla Telegram.Client adapter. Currently it uses gun and the Retry middleware (with default opts)

lawik commented 2 years ago

It also happens with both {:file_content, binary, name} and {:file, path} variants which was surprising.

I just tried switching the entire client to Hackney. Went through, no issue. So this is probably an issue with Gun then.

Seems similar to this: https://github.com/elixir-tesla/tesla/issues/230

visciang commented 2 years ago

Exactly what I expected! Maybe more close https://github.com/elixir-tesla/tesla/issues/394.

Honestly, the HTTP side of things is really horrible Erlang/Elixir side. (even more now, when 99% of the beam app find application in the web and the 5G inter-NF is HTTP based).

lawik commented 2 years ago

Well found! That is the exact issue but not the same HTTP client. I haven't had many problems with the HTTP-clients but I'll take your word for it :)

lawik commented 2 years ago

Is there a particular reason this library configures Gun and not another HTTP library? Can it be overridden with config?

I don't have time to figure out the Tesla problem but switching to Hackney seems to work fine.

visciang commented 2 years ago

No particular reason.

The tesa client adapter and its config could be made configurable, ie the library user can choose what to use or just leave the default (hackney).

And, by the way, the need to have an HTTP client stays in the pooler, that should be used in dev mode or if serving small amount of traffic. Another way to say it doesn't matter that much what client you use unless you have strong dependency requirements.

visciang commented 2 years ago

@lawik could you give a quick review to https://github.com/visciang/telegram/pull/138 ?