-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
[BUG] ZeroMQ Transport Error on Timeout/Exception #66006
Labels
Bug
broken, incorrect, or confusing behavior
Milestone
Comments
noticing similar error trying to start minion on rocky9 vagrant instance
|
2 tasks
Closed
2 tasks
This was released in 3006.7 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
When sending a message via the ZeroMQ transport in
3006.5
, a flurry ofERROR
logs are seen if the request times out or an exception occurs during execution.These messages are not indicative of a functional issue - the response is received by the Salt Minion and it returns as expected (note the last line displaying the clear "timeout error") - but are part of the completion of the
coroutine
that the message sending/receiving now runs in.The root cause of these messages is the fact that the error handling code does not check if the
future
isdone
(meaning it will have already yielded to the calling code, hence the lack of impact, apart from logging) before attempting to set the exception.Setup
This was produced in a local environment with a code change to reliably replicate the situation:
I introduced a 30 second sleep in the
channel/server
implementation to artificially create a timeout when signing into the Salt Master.Steps to Reproduce the behavior
auth_timeout: 1
(this is not necessary, just speeds up demonstration of the issue)Expected behavior
When an exception occurs but the
future
is already done (meaning the calling process received a response - whatever it may be), thecoroutine
does not attempt to complete thatfuture
again and end up dumping a bunch of spuriousERROR
logs.Versions Report
Note This report was taken with code at the
v3006.5
tag (0472fd3) but shows up as3007.0
below for somesalt --versions-report
reason.The text was updated successfully, but these errors were encountered: