-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Dry up TransportResponseHandler #64395
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
Dry up TransportResponseHandler #64395
Conversation
The majority of implementations of this interface run on `SAME`. Drying this up saves some duplication and also makes it a little easier to understand what callbacks won't fork-off when reading the code.
Pinging @elastic/es-core-infra (:Core/Infra/Core) |
Jenkins run elasticsearch-ci/bwc |
…response-handlers
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.
This looks fine, but is there any reason this couldn't live as a default implementation of executor()
on the TransportResponseHandler interface?
yea that's the cleaner approach indeed -> moved to that now thanks! :) |
Jenkins run elasticsearch-ci/2 |
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.
LGTM
Thanks Ryan! |
The majority of implementations of this interface run on `SAME`. Drying this up saves some duplication and also makes it a little easier to understand what callbacks won't fork-off when reading the code.
I keep typing this over and over so I figured I'd dry it up:
The majority of implementations of this interface run on
SAME
.Drying this up saves some duplication and also makes it a little
easier to understand what callbacks won't fork-off when reading the
code.