Skip to content
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

Clarify double-response exception #124706

Conversation

DaveCTurner
Copy link
Contributor

@DaveCTurner DaveCTurner commented Mar 13, 2025

It is confusing to readers to report Channel is already closed in
reaction to a double-response bug, and this may be interpreted as a
networking issue. We're not really closing anything here, and it's a
definite logic bug to call sendResponse() twice, so this commit
clarifies the actual problem in the exception message.

Relates ES-10996

It is confusing to readers to report `Channel is already closed` in
reaction to a double-response bug, and this may be interpreted as a
networking issue. We're not really closing anything here, and it's a
definite logic bug to call `sendResponse()` twice, so this commit
clarifies the actual problem in the exception message.
@DaveCTurner DaveCTurner added >non-issue :Distributed Coordination/Network Http and internode communication implementations v8.19.0 v9.1.0 labels Mar 13, 2025
@elasticsearchmachine elasticsearchmachine added the Team:Distributed Coordination Meta label for Distributed Coordination team label Mar 13, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination)

Copy link
Contributor

@mhl-b mhl-b left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

close();
// protect against double-response bugs
if (responseSent.compareAndSet(false, true) == false) {
final var message = "have already sent a response to this request, cannot send another";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cannot send another

we can but we wont

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's an implicit "without violating the HTTP spec" here I guess ;)

Copy link
Contributor

@mhl-b mhl-b Mar 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HTTP Spec:

First shalt thou create the HTTP Response. Then shalt thou count to one, no more, no less. One shall be the number thou shalt count, and the number of the counting shall be one. Two shalt thou not count, neither count thou three, excepting that thou then proceed to one. Five is right out. Once the number one, being the first number, be reached, then lobbest thou thy HTTP Response towards thy foe, who, being naughty in My sight, shall snuff it.

@DaveCTurner DaveCTurner added auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) auto-backport Automatically create backport pull requests when merged labels Mar 13, 2025
@elasticsearchmachine elasticsearchmachine merged commit 519381f into elastic:main Mar 13, 2025
18 checks passed
@DaveCTurner DaveCTurner deleted the 2025/03/13/double-close-rest-message branch March 13, 2025 15:49
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

Status Branch Result
8.x Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 124706

jfreden pushed a commit to jfreden/elasticsearch that referenced this pull request Mar 13, 2025
It is confusing to readers to report `Channel is already closed` in
reaction to a double-response bug, and this may be interpreted as a
networking issue. We're not really closing anything here, and it's a
definite logic bug to call `sendResponse()` twice, so this commit
clarifies the actual problem in the exception message.

Relates ES-10996
DaveCTurner added a commit to DaveCTurner/elasticsearch that referenced this pull request Mar 13, 2025
It is confusing to readers to report `Channel is already closed` in
reaction to a double-response bug, and this may be interpreted as a
networking issue. We're not really closing anything here, and it's a
definite logic bug to call `sendResponse()` twice, so this commit
clarifies the actual problem in the exception message.

Relates ES-10996

Backport of elastic#124706 to `8.x`
@DaveCTurner
Copy link
Contributor Author

Backport is #124809

elasticsearchmachine pushed a commit that referenced this pull request Mar 13, 2025
It is confusing to readers to report `Channel is already closed` in
reaction to a double-response bug, and this may be interpreted as a
networking issue. We're not really closing anything here, and it's a
definite logic bug to call `sendResponse()` twice, so this commit
clarifies the actual problem in the exception message.

Relates ES-10996

Backport of #124706 to `8.x`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Automatically create backport pull requests when merged auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) :Distributed Coordination/Network Http and internode communication implementations >non-issue Team:Distributed Coordination Meta label for Distributed Coordination team v8.19.0 v9.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants