-
-
Notifications
You must be signed in to change notification settings - Fork 682
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debuglink timing out fix #4655
base: main
Are you sure you want to change the base?
Debuglink timing out fix #4655
Conversation
|
ef0638f
to
237540f
Compare
6f67eee
to
0f01352
Compare
also take the opportunity to switch to new style typing annotations syntax
...avoiding a problem where, if the timing is unfortunate, the reply may get lost when a workflow is ending
2212550
to
3056b49
Compare
continue | ||
if timeout is not None and time.time() - start > timeout: | ||
raise TransportException("Timeout reading UDP packet") | ||
time.sleep(0.001) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why do we need time.sleep()
here, since the socket has a timeout set too:
self.socket.settimeout(SOCKET_TIMEOUT) |
# XXX Due to a bug, the reply may get lost at the end of a workflow. | ||
# We assume that no single input event takes more than 5 seconds to process, | ||
# and give up waiting after that. | ||
self._call(messages.DebugLinkGetState(return_empty_state=True), timeout=5) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So just to be sure - we raise an exception here, right?
Asking, since IIRC there was a suggestion to ignore the timeout (i.e. to assume the request has been processed by the device), but then I would suggest also logging that there was an ignored timeout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can use an environment variable to set the timeout?
IIUC, it may take the device more than 5 seconds to respond, e.g. when running WipeDevice
.
No description provided.