Describe the idea
Suppose you have a Rails middleware that does this:
def call ( env )
return [ 200 , { 'Content-Type' => 'text/plain' } , 'hi' ]
end
Since 'hi' does not respond to each as specified in the Rack spec (https://github.com/rack/rack/blob/master/SPEC.rdoc#label-The+Body ), this fails quietly in the Web server with this message:
#<NoMethodError: undefined method `each' for "hi":String>
Other users have reported this in puma/puma#1782 .
Why do you think it's beneficial to most of the users
While this problem is clearly a bug in the middleware, we've come across it enough times that sometimes it takes a long to troubleshoot. The backtrace is not always available, and the log messages are hidden away in an unstructured stderr output. It's surprising that this exception isn't reported via Sentry.
Possible implementation
Capturing this exception might depend on integration with the Web server in question. For example, if you use Thin, the exception is encountered here: https://github.com/macournoyer/thin/blob/0712d603a31d97b9fa8a0260da400da2e4217d60/lib/thin/connection.rb#L114-L123
For Puma, there is this low-level error handler: https://github.com/puma/puma#error-handling . Perhaps it makes sense to hook Sentry up to the Puma ErrorLogger? https://github.com/puma/puma/blob/v5.3.2/lib/puma/error_logger.rb
Note that the exception is:
Hit on this line: https://github.com/puma/puma/blob/bda19f8225a36f83bb2671fc4baef870df9f76b4/lib/puma/request.rb#L149 .
Rescued here: https://github.com/puma/puma/blob/f4766ce46976ec623f163a0428515d157f53e420/lib/puma/server.rb#L476
Reported here: https://github.com/puma/puma/blob/f4766ce46976ec623f163a0428515d157f53e420/lib/puma/server.rb#L517
Logged here: https://github.com/puma/puma/blob/f4766ce46976ec623f163a0428515d157f53e420/lib/puma/events.rb#L123
The backtrace shows:
lib/ruby/gems/2.7.0/gems/rack-2.2.3/lib/rack/body_proxy.rb:41:in `method_missing'
lib/ruby/gems/2.7.0/gems/rack-2.2.3/lib/rack/body_proxy.rb:41:in `method_missing'
lib/ruby/gems/2.7.0/gems/rack-2.2.3/lib/rack/body_proxy.rb:41:in `method_missing'
lib/ruby/gems/2.7.0/gems/rack-2.2.3/lib/rack/body_proxy.rb:41:in `method_missing'
lib/ruby/gems/2.7.0/gems/rack-2.2.3/lib/rack/body_proxy.rb:41:in `method_missing'
lib/ruby/gems/2.7.0/gems/puma-5.3.2/lib/puma/request.rb:149:in `handle_request'
lib/ruby/gems/2.7.0/gems/puma-5.3.2/lib/puma/server.rb:438:in `process_client'
lib/ruby/gems/2.7.0/gems/puma-5.3.2/lib/puma/thread_pool.rb:145:in `block in spawn_thread'
Similar issues:
SignalException: SIGTERM not caught by sentry-raven #917 .
https://forum.sentry.io/t/puma-exception-handling/979 .
Describe the idea
Suppose you have a Rails middleware that does this:
Since
'hi'does not respond toeachas specified in the Rack spec (https://github.com/rack/rack/blob/master/SPEC.rdoc#label-The+Body), this fails quietly in the Web server with this message:Other users have reported this in puma/puma#1782.
Why do you think it's beneficial to most of the users
While this problem is clearly a bug in the middleware, we've come across it enough times that sometimes it takes a long to troubleshoot. The backtrace is not always available, and the log messages are hidden away in an unstructured
stderroutput. It's surprising that this exception isn't reported via Sentry.Possible implementation
Capturing this exception might depend on integration with the Web server in question. For example, if you use Thin, the exception is encountered here: https://github.com/macournoyer/thin/blob/0712d603a31d97b9fa8a0260da400da2e4217d60/lib/thin/connection.rb#L114-L123
For Puma, there is this low-level error handler: https://github.com/puma/puma#error-handling. Perhaps it makes sense to hook Sentry up to the Puma
ErrorLogger? https://github.com/puma/puma/blob/v5.3.2/lib/puma/error_logger.rbNote that the exception is:
The backtrace shows:
Similar issues: