mirror of
https://github.com/airmessage/airmessage-server.git
synced 2026-04-26 01:05:50 +03:00
[GH-ISSUE #13] AirMessage server gives up when network is down. #15
Labels
No labels
bug
enhancement
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/airmessage-server#15
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bhyde on GitHub (Jul 2, 2022).
Original GitHub issue: https://github.com/airmessage/airmessage-server/issues/13
Originally assigned to: @tagavari on GitHub.
My internet service has occasional short outages. Of course when that happens, AirMessage notices it can't reach the internet. This makes it so sad it gives up.
At that point my Android AirMessage App notices that it can't reach the server. This makes it sad. So it throws up it's hands and gives up.
Then my loving correspondents send me some messages. I don't get these. They think I'm a jerk. This makes me sad.
The server's menu-ui shows a "Retry" choice. That has never worked for me. But killing and restarting the server makes things better... kind of.
I think, both the server and client should be more persistent. Giving up makes me look bad. We are all sad about that, I'm sure.
@bhyde commented on GitHub (Jul 2, 2022):
One way to restart the server is this bash hack:
Of course, running that will trigger all AirMessage clients of the server to give up, if they haven't already.
A better script would only kill the server if it has given up. I haven't puzzled out a way to discover that from a script.
@tagavari commented on GitHub (Jul 2, 2022):
Thank you for bringing up this issue, this is certainly something I'd like to look into resolving.
Is this an issue you're able to recreate consistently? If you turn off your Mac's Wi-Fi and turn it back on, does this problem occur?
@mkitchingh commented on GitHub (Jul 2, 2022):
Same issue. I should have opened an issue here. I put a couple of posts in the Reddit group instead. Sorry. Every time I get a drop in my home Internet connection, I have have to restart the AirMessage server app. It is stuck in the condition described above. Clicking the retry option on the server doesn't help.
@tagavari commented on GitHub (Jul 2, 2022):
@mkitchingh Thanks for pitching in, the more information I can gather on this the better.
Can I ask what happens when you click the Retry button, as well as what version of macOS and AirMessage Server you're running?
@mkitchingh commented on GitHub (Jul 2, 2022):
Nothing happens when I click retry. I just upgraded from the latest alpha to the general release today. I'm running Monterey with the latest updates. Confirmed today.
@tagavari commented on GitHub (Jul 2, 2022):
@mkitchingh I see, that's good to know. Is this an issue you're able to recreate consistently?
Turning Wi-Fi off for a few moments and then turning it back on doesn't cause any issues for me. Does the computer need to be disconnected for a long period of time?
@bhyde commented on GitHub (Jul 3, 2022):
I was just prompted to upgrade from alpha to the latest release, so I did.
Demonstrating that the client doesn't try to restart, or at least not very hard, is easy. Just kill and immediately restart the server.
My ISP gifts me very short outages, i don't thing it requires a long one to get the server to fail to retry on it's own. But I could be wrong.
My AirMessage server is on a Mac that has only a Ethernet connect to my local LAN. That's via a thunderbolt to Ethernet adaptor.
I just spent a bit of time seeing if I could trigger the issue by running sudo ifconfig en3 down; sleep $X; sudo ifconfig en3 up. But no luck, for various values of $X. I'm surprised that didn't trigger the client into deciding it should settle into the retry state.
Maybe I can do some more testing tomorrow, we shall see.
@tagavari commented on GitHub (Jul 3, 2022):
@bhyde Thank you for the details. I'll leave the server running offline on my computer for a while to see if I can bring up the same issue.
To confirm, are you using the Android client with a Google account?
@mkitchingh commented on GitHub (Jul 3, 2022):
I'm traveling out of the country for the next couple days, and it will be a little hard to test. Mine is a Mac M1 mini using me on board ethernet adapter. A relatively short outage ftom my ISP seems to trigger the issue. I'll see how I can reproduce it when I get home.
@tagavari commented on GitHub (Aug 6, 2022):
Okay, this boils down to 2 problems:
I'm testing a new release with these changes locally across my devices, and will be releasing it to the beta channel as v4.1.1 if everything goes smoothly.
Thank you all for your patience!
@tagavari commented on GitHub (Aug 10, 2022):
This has been resolved in version 4.1.1.
@bhyde commented on GitHub (Aug 14, 2022):
I upgraded to 4.1.1 shortly after the comment above (i.e. "This has been resolved in version 4.1.1"), and it worked fine until a few hours ago. The client lost it's connection, and retry wasn't helping. Later I discovered the client was displaying a brief error in it's pull down menu. That said "An external error occurred." or something similar. Selecting retry from that same menu restored the server at which point telling the client to retry fixed things.
Thanks for your efforts to fix this!