-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Add suport for rack.response_finished #3631
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
Conversation
9c9cf7c
to
6628ab9
Compare
This is great. Being able to use the default |
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.
Pull Request Overview
This PR adds support for the rack.response_finished hook by sharing its callable array with rack.after_reply.
- New tests in test/test_rack_server.rb to verify both normal and exceptional behavior of rack.response_finished.
- Updates to lib/puma/request.rb to assign rack.response_finished the same array as rack.after_reply.
- Addition of the RACK_RESPONSE_FINISHED constant in lib/puma/const.rb.
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
File | Description |
---|---|
test/test_rack_server.rb | Added tests to verify normal and exception behaviors for rack.response_finished. |
lib/puma/request.rb | Assigned rack.response_finished to share the callable array with rack.after_reply. |
lib/puma/const.rb | Added a new constant RACK_RESPONSE_FINISHED to support the new functionality. |
sleep 0.1 | ||
assert_raises IO::WaitReadable do | ||
content = socket.read_nonblock(12) | ||
refute_includes content, "500" |
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.
[nitpick] Using a fixed sleep duration can potentially lead to flaky tests if the timing varies. Consider replacing it with a polling or waiting mechanism to check for the expected behavior.
sleep 0.1 | |
assert_raises IO::WaitReadable do | |
content = socket.read_nonblock(12) | |
refute_includes content, "500" | |
# Wait for the socket to become readable within 0.1 seconds. | |
readable, = IO.select([socket], nil, nil, 0.1) | |
if readable | |
content = socket.read_nonblock(12) | |
refute_includes content, "500" | |
else | |
# If the socket is not readable, assume no extra content was written. | |
assert_raises IO::WaitReadable do | |
socket.read_nonblock(12) | |
end |
Copilot uses AI. Check for mistakes.
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.
Suggested change may not be exactly what we should do but I agree with the intent of the suggestion
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.
Yeah to be honest I just mirrored the test for rack.after_reply
, if the maintainers want to see this test updated I can also make those changes there as well.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@nateberkopec 👋 would appreciate your 👀 on this. Thanks! |
This looks like a good addition. Looking at rack/rack#1777, rack/rack#1802, rack/rack#1952, and Shopify/pitchfork#98. Not sure if the call loop should be updated to match what the pitchfork code did, I think one or more of the Puma call loops was/were changed to rescue within the loop rather than outside of it. That was part of the pitchfork PR. |
Adding more reliability to these hooks is a desirable trait in my opinion, should I make that change as part of this PR? |
Add Since the rack spec does state 'They should be invoked in reverse order of registration', I think it would be best to reverse the call array for Given the current behavior, maybe Puma should run the Lastly, as mentioned previously, should these calls be rescued inside or outside of the loop? |
It is very similar to `rack.after_reply`, but is part of the Rack spec. It can't just be an alias because the spec state it has to invoke callbacks in reverse order. Fix: puma#3631 Ref: rack/rack#1777 Ref: rack/rack#1802
It is very similar to `rack.after_reply`, but is part of the Rack spec. It can't just be an alias because the spec state it has to invoke callbacks in reverse order. Fix: puma#3631 Ref: rack/rack#1777 Ref: rack/rack#1802 Co-Authored-By: Robert Laurin <robert.laurin@shopify.com>
It is very similar to `rack.after_reply`, but is part of the Rack spec. It can't just be an alias because the spec state it has to invoke callbacks in reverse order. Fix: puma#3631 Ref: rack/rack#1777 Ref: rack/rack#1802 Co-Authored-By: Robert Laurin <robert.laurin@shopify.com>
It is very similar to `rack.after_reply`, but is part of the Rack spec. It can't just be an alias because the spec state it has to invoke callbacks in reverse order. Fix: puma#3631 Ref: rack/rack#1777 Ref: rack/rack#1802 Co-Authored-By: Robert Laurin <robert.laurin@shopify.com>
* Add support for `rack.response_finished` It is very similar to `rack.after_reply`, but is part of the Rack spec. It can't just be an alias because the spec state it has to invoke callbacks in reverse order. Fix: puma#3631 Ref: rack/rack#1777 Ref: rack/rack#1802 Co-Authored-By: Robert Laurin <robert.laurin@shopify.com> * request.rb - more rename `e` to `error` changes --------- Co-authored-by: Robert Laurin <robert.laurin@shopify.com> Co-authored-by: MSP-Greg <Greg.mpls@gmail.com>
Description
Looking to add support for racks response finished hooks.
It is my understanding that the expected use of
rack.after_reply
andrack.response_finished
are the same, so for this PR I opted to have them share the callable array instead of duplicating theafter_reply
behaviour just forresponse_finished
.Your checklist for this pull request
[ci skip]
to the title of the PR.#issue
" to the PR description or my commit messages.