What I’m trying to do:
Understand an Internal server error
so I can prevent it in the future.
What I’ve tried and what’s not working:
Since it’s an internal error, all I can really try to do is report it, as here.
I won’t know whether that’s working until somebody looks at it and replies.
Code Sample:
"""Client Module client_globals
"""
#web-service imports
import anvil.server
# Python standard library
import datetime
# global variables and initial values:
app_version_from_db = ''
app_version_from_source = ''
status_flags = None
def heartbeat(new_login = False):
"""Notifies server that client (browser) is still running the app.
If a user has just now logged in, passes that information along
for proper user setup. System may reject the log-in for various
reasons (e.g., wrong permissions, or pending shutdown).
Receives application status information,
caches it in this module for use across many forms,
and returns it to caller.
"""
global status_flags
status_flags = anvil.server.call('receive_client_heartbeat', datetime.datetime.now(), new_login)
planned_shutdown_time = status_flags['planned_shutdown_time']
return status_flags
Error message:
undefined: Internal server error: 99fec7d9f3b6
at client_globals, line 26
called from Label_Maint_Status, line 68
Line 26 is the anvil.server.call
above. heartbeat
is called periodically to let the App know that the Client is still connected. When the heartbeats stop for too long, we assume that the browser has disconnected.
This error occurred after letting the App run in the IDE overnight, and logging back in to Windows 10 the next morning (today).
I suspect that the browser shut down the tab overnight, after some period of inactivity. The browser is Firefox 91.0.2 (64-bit). Three other instances of Firefox were running. In this instance, there was only one tab open: the Anvil IDE.
Clone link:
Not practical for an app of this size. I hope I have included enough information to replicate the problem.
I have the heartbeat
function in one app to keep it signed in, just like you, and in two apps that I monitor with uptimerobot.com.
This morning that app had an error and last night at 3:43 I received an email from both the monitors with this message:
The monitor [...] is currently DOWN (HTTP 500 - Internal Server Error)
**Event timestamp:** 2021-08-27 03:43:46 UTC-5
I see this happening a handful of times a year, and I always receive an email that the monitor is back up at the next check after 5 minutes (I’m on the uptimerobot free plan).
I sometimes do report the internal error to the Anvil support, but I’m not worried. I file these sporadic errors under the Anvil updates / maintenance / network error / whatever folder.
In that case, I’m not going to worry about it. It’s probably not a Firefox-created problem, and there isn’t much for me to do except report the occurrence, anyway. I’ve held on to that browser tab, unchanged, for awhile, in case someone asks for debugging info. But I’ll soon get back to work on the App.
As for user impact, my app trapped the exception, and asked the user to refresh the browser. No data was lost. So in practice, while it may make my app look like it is unreliable, the physical impact is negligible.
In a widely-interconnected world, I guess we have to expect these things now and again, and just program around them to the best of our ability. In part, I’m still used to developing desktop apps, where a faraway glitch has no effect whatsoever.
Thanks, @stefano.menci .
I have another app with the same problem: a queue manager that executes long running tasks on 3 uplink servers. The UI is just a repeating panel that shows what’s in the queue by polling every 2 seconds.
I like to keep my eyes on it so I can catch anything wrong in what the app does and what the users ask it to do. I have a browser open on that app 24/7, so it happens once a week or more that I see that red panel reporting a communication error. In a bad stormy day I could get it 3-4 times in an hour.
Every time I see it I think that I should wrap the polling call in a try - except
block, so users don’t have the feeling that something is wrong. The except
could show or hide a banner when there are problems, it would be a nicer approach. I could test it by unplugging the network cord or turning off the wifi.
One day I will do that, I promise!
1 Like
We did indeed have a brief outage around 6 hours ago, which may well be responsible for the errors you’ve seen. Please keep letting us know when you see these kinds of errors though, because if they occur when we don’t think they’ve been caused by a known outage, we’d very much like to know!
2 Likes