-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Code coverage not working with Puma 6.2 #600
Comments
nice ! I would have never thought.... this is really helpful. would you mind opening a PR with the fix ? is it backward compatible with puma 6.1 and below or we need a conditional ? |
cc: @phenchaw |
I've tested and confirmed that the fix works with Puma 6.3.1, 6.2.2, 6.1.1, 6.0.1, 5.6.7, and 5.0.4. I've opened PR #601 |
truly awesome, thanks |
mathieujobin
pushed a commit
that referenced
this issue
Sep 5, 2023
Tests are failing on Puma 6.2 (and newer) when instrumentation is enabled. This seems to be caused by PR #3072 in Puma which changes how it handles responses. If the body (3rd argument) is a file-like object (which Asset is) then it appears to be getting the file path and reading the original contents which then doesn't match the modified Content-Length header for the instrumented version. This commit fixes the issue by returning the instrumented source as a string rather then the Asset object.
released in v1.4.0 |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
I just upgraded Puma from from 6.1 to 6.2 and suddenly all my teaspoon tests failed. After quite a bit of digging I found out it was to do with the code coverage - specifically how the assets are instrumented.
I added this monkey patch to my
teaspoon_env.rb
file which seems to fix it:I'm thinking the issue is due to PR #3072 in Puma and the original Teaspoon::Instrumentation#instrumented_response method returning an
Asset
object which has file-like methods (e.g.#filename
and#bytesize
). I'm wondering if Puma 6.2 is trying to read the original asset file, but is getting thrown off because we've updated the content-length. Either way changing theinstrumented_response
method to return the modified file contents as a string seems to fix it.The text was updated successfully, but these errors were encountered: