-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Removed the jitter timeout from Mercury Transmitter #15717
base: develop
Are you sure you want to change the base?
Conversation
I see you updated files related to
|
AER Report: CI Core ran successfully ✅AER Report: Operator UI CI ran successfully ✅ |
6a39a5e
to
bd0296a
Compare
5e9a1f8
to
86954b0
Compare
86954b0
to
41426de
Compare
res, err := func(ctx context.Context) (*pb.TransmitResponse, error) { | ||
ctx, cancel := context.WithTimeout(ctx, utils.WithJitter(s.transmitTimeout)) | ||
cancel() | ||
return s.c.Transmit(ctx, t.Req) | ||
}(ctx) |
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.
The closure only existed to support this context, so it can be removed:
res, err := s.c.Transmit(ctx, t.Req)
That sounds like a bug in the transmitter, not with the callers. If this method is going to accept a context, then it must handle timeouts correctly, and if we have unusual expectations then they should be documented. Do we have a ticket to track the root cause? |
d202d06
41426de
to
d202d06
Compare
d202d06
to
af4d1da
Compare
This reverts the issue with the jitter timeout on the Mercury Transmitter. It was causing the transmitter queue to get stuck and grow until we hit the limit.