I can repro this most of the time: sending to someone else is ok, sending to the account who's QR code I scanned fails with timeout when sending. I'm on master due to #409.
What happens is, I'm actually receiving the message, but the code keeps hanging in the send loop:
wac, err := whatsappLogin()
if err != nil {
log.Fatal(err)
}
text := whatsapp.TextMessage{
Info: whatsapp.MessageInfo{
RemoteJid: "[email protected]",
FromMe: true,
},
Text: "foo",
}
if res, err := wac.Send(text); err != nil {
log.Fatal(err)
} else {
println(res)
}
gives
2020/07/12 10:33:02 sending message timed out
I've added some diagnostics. Here is the write log for a different user:
2020/07/12 13:14:31 write messageType:2, answerMessageTag:C3CB47E91F4EE88C4E45
2020/07/12 13:14:31 processReadData msgType:2 hasListener:false
2020/07/12 13:14:31 processReadData msgType:1 hasListener:true
here is the write log for my user:
2020/07/12 13:15:11 write messageType:2, answerMessageTag:5399DA23AD50C62314BC
2020/07/12 13:15:12 processReadData msgType:2 hasListener:false
2020/07/12 13:15:13 processReadData msgType:2 hasListener:false
2020/07/12 13:15:13 processReadData msgType:2 hasListener:false
2020/07/12 13:15:13 processReadData msgType:2 hasListener:false
2020/07/12 13:15:13 processReadData msgType:2 hasListener:false
2020/07/12 13:15:13 processReadData msgType:2 hasListener:false
2020/07/12 13:15:13 processReadData msgType:2 hasListener:false
2020/07/12 13:15:14 processReadData msgType:2 hasListener:false
2020/07/12 13:15:14 processReadData msgType:2 hasListener:false
2020/07/12 13:15:14 processReadData msgType:2 hasListener:false
2020/07/12 13:15:14 processReadData msgType:2 hasListener:false
2020/07/12 13:15:14 processReadData msgType:2 hasListener:false
2020/07/12 13:15:14 processReadData msgType:2 hasListener:false
2020/07/12 13:15:28 processReadData msgType:2 hasListener:false
2020/07/12 13:15:31 sending message timed out
so processReadData receives multiple type 2 responses but never any type 1 response for the answer tag.
/cc @Rhymen is there anything I could contribute in terms of diagnosis? I‘m proficient in go debugging but would need a pointer what to look into.
Hello
I can not see why this happens to you!
I just test the API and I can send my self with no problem!
My guess is that the same problem could happen when sending to any number and is not specific for sending to myself. Anyway it seems as if the expected msgType:1 answer is never received.
Might be a duplicate of https://github.com/Rhymen/go-whatsapp/issues/190
/cc @SchulteMK regarding timeout 20sec after sending
@Rhymen this issue is still present after your recent cleanup. Anything I could do apart from the logs above?
Any feedback on this one as to why sending times out?
@andig i think because your WhatsApp is closed from your phone, make sure to whatsapp always open
i think because your WhatsApp is closed from your phone, make sure to whatsapp always open
Unfortunately not. WA is still open on my phone when this happens. @tarikhagustia could you confirm if you are able to send an WA message to yourself?
I am seeing the same issue basically.
I am running a connection with one handler attached and when I send a message to myself on that connection I get a timeout error on send. The message does arrive on my phone though.
Additionally, the handler fails with processing data: received invalid data when trying to receive that same message. When sending messages from myself to myself on the phone the handler can receive those messages though.
I am running the receiver and sender on different threads using the same Conn object, idk if that matters.
You are sending a message from the same to the same number? Is it possible in the normal WA web? And if so, why?
@normen How do you run the receiver and sender in different threads/goroutines?
In this package, the receive queue is already on a separate goroutine and sending is handled in the context of the caller. And depending on if your handler implements ShouldCallSynchronously() or not, the call to the externally controlled handler is dispatched in a separate goroutine. Can you maybe give us a short code example?
Yeah, I see that the dispatch of messages is done in a different go routine in go-whatsapp. I put all messages I receive into a channel that is drained by the same thread that started the connection and set the handler.
pseudo-code:
go func(){
conn := wac.GetConnection()
wac.AddHandler(handler)
for range(sendChannel){
wac.sendMessage(messageFromChannel)
}
}
// handler
func (t textHandler) HandleTextMessage(msg whatsapp.TextMessage) {
sendChannel <- msg
}
Am 17.11.2020 02:58 schrieb Marcel Kocks:
You are sending a message from the same to the same number? Is it possible in the normal WA web? And if so, why?
@normen How do you run the receiver and sender in different threads/goroutines?
In this package, the receive queue is already on a separate goroutine and sending is handled in the context of the caller. And depending on if your handler implementsShouldCallSynchronously()or not, the call to the externally controlled handler is dispatched in a separate goroutine. Can you maybe give us a short code example?--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/Rhymen/go-whatsapp/issues/410#issuecomment-728852487
Oh and heres the project where I actually get the issue, you can remove the workaround I mentioned to see the issue: https://github.com/normen/whatscli
Am 17.11.2020 02:58 schrieb Marcel Kocks:
You are sending a message from the same to the same number? Is it possible in the normal WA web? And if so, why?
@normen How do you run the receiver and sender in different threads/goroutines?
In this package, the receive queue is already on a separate goroutine and sending is handled in the context of the caller. And depending on if your handler implementsShouldCallSynchronously()or not, the call to the externally controlled handler is dispatched in a separate goroutine. Can you maybe give us a short code example?--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/Rhymen/go-whatsapp/issues/410#issuecomment-728852487
@normen How do you run the receiver and sender in different threads/goroutines?
Additionally, the handler fails with processing data: received invalid data when trying to receive that same message. When sending messages from myself to myself on the phone the handler can receive those messages though.
In my case (initial issue on top) I didn't even think about attaching a listener. My assumption was the listener would be on the phone.
@SchulteMK It seems you're saying that there should be an accompanying listener in a separate go routine?
Sounds like there is something strange happening while sending a message to yourself.
Maybe I can take a look at this issue this evening. Apart from that: Why do you want to send a message to yourself? Am I missing something?
@SchulteMK It seems you're saying that there should be an accompanying listener in a separate goroutine?
No, you do not need an extra listener.
The way @normen implemented his receiving is pretty clever if you depend on other resources that cannot easily be shared. If his channel is buffered he could even let go-whatsapp dispatch the messages synchronously.
It is really important, let's say you have a notification system on your
server and you want to send your self some notification!
On Tue, Nov 17, 2020 at 4:30 PM Marcel Kocks notifications@github.com
wrote:
Sounds like there is something strange happening while sending a message
to yourself.
Maybe I can take a look at this issue this evening. Apart from that: Why
do you want to send a message to yourself? Am I missing something?—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Rhymen/go-whatsapp/issues/410#issuecomment-728965317,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABDLT272X2DJLOWGQCM6C33SQKCH3ANCNFSM4OU34M2A
.
Okay, I use it that way too, but I bought a spare SIM card and put it on an old phone.
I use WhatsAppWeb for myself all the time, so your approach would not fit me.
I can see the point. Hopefully, I got time to look into this issue.
In my case simply for testing without spamming other users or my wife.
Did you test if sending a message to yourself in the original WhatsAppWeb works?
Sounds like there is something strange happening while sending a message to yourself.
Maybe I can take a look at this issue this evening. Apart from that: Why do you want to send a message to yourself? Am I missing something?
No, this issue happens no matter where I send the message. I can't listen and send at the same time, period. Notably theres also no such example in this repo.
Did you test if sending a message to yourself in the original WhatsAppWeb works?
As a Charm!
Okay, I use it that way too, but I bought a spare SIM card and put it on an old phone.
I use WhatsAppWeb for myself all the time, so your approach would not fit me.
I can see the point. Hopefully, I got time to look into this issue.
You are our only hope :D
Okay, now I get your issue @normen. It took some time...
Sending and receiving at the same time should work though. It is a mandatory feature I guess :D
We used this API as a chatbot for around 20 people at the same time and never encountered an issue. But this was over a year ago.
I see. If you have any pointers on where to look for what apart from general debugging I'll check that, for now I have a workaround and rather add features to my app than debugging this.
Am 17.11.2020 06:45 schrieb Marcel Kocks:
Okay, now I get your issue @normen. It took some time...
Sending and receiving at the same time should work though. It is a mandatory feature I guess :D
We used this API as a chatbot for around 20 people at the same time and never encountered an issue. But this was over a year ago.--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/Rhymen/go-whatsapp/issues/410#issuecomment-728975124
Sorry, realizing that I described the workaround I mentioned in issue #302
Your workaround is far from ideal, it only stops the error propagation to your handler. I will see if I can reproduce the issue and fix it.
Your workaround is far from ideal, it only stops the error propagation to your handler. I will see if I can reproduce the issue and fix it.
Cool, thanks! Let me know if I can help.
Most helpful comment
In my case simply for testing without spamming other users or my wife.