This should have been fixed in this commit:
http://github.com/thoughtbot/hoptoad_notifier/commit/da5bc5a09f0d887e114e2d3aa86268330e05e513
Thanks,
Dan
On Mon, Apr 13, 2009 at 3:47 AM, Ryan Tomayko r...@heroku.com wrote:
On Sun, Apr 12, 2009 at 8:44 PM, shenry stuarthe...@gmail.com wrote:
I have this same problem, Hoptoad will correctly send a message after
heroku rake hoptoad:test but if I create an exception manually I get
nothing
Hoptoad Success: Net::HTTPOK
Rendering /disk1/home/slugs/2185_8e050c1_3bb1/mnt/public/500.html (500
Internal Server Error)
Any ideas?
There's an open bug in the hoptoad plugin. Full detail below but the
quick workaround is to add async. to the environment_filters in
config/initializers/hoptoad.rb as follows:
HoptoadNotifier.configure do |config|
config.api_key = 'YOUR KEY'
config.environment_filters 'async.'
end
This causes the notifier to remove any matching keys before building
the YAML payload to send to hoptoad.
Here's my original write up on the issue. I'm under the impression
that the thoughtbot folks are aware of this. Maybe someone on the list
can bring it to the right person's attention:
This issue occurs when there are complex objects in the request
environment. The hoptoad plugin builds a POST body to send to the
hoptoad server by converting the session, environment, request,
backtrace, and error_message into YAML. Heroku loads a special version
of Thin that places two special variables in the environment:
async.callback and async.close. These are both Proc/Method objects
but could theoretically be any object not directly serializeable to
YAML. When these objects are converted to YAML, they look like this:
async.callback: !ruby/object:Method {}
I assume some kind of deserialization exception is occurring on the
hoptoad server when an attempt is made to parse the YAML. The right
fix is probably to adjust the following code in the hoptoad plugin:
def clean_non_serializable_data(notice) #:nodoc:
notice.select{|k,v| serializable?(v) }.inject({}) do |h, pair|
h[pair.first] = pair.last.is_a?(Hash) ?
clean_non_serializable_data(pair.last) : pair.last
h
end
end
def serializable?(value) #:nodoc:
!(value.is_a?(Module) || value.kind_of?(IO))
end
The serializable? check should probably be a whitelist of allowed
value types instead of a blacklist of disallowed value types. Adding
Method/Proc to the current list of disallowed types would also solve
this issue but it will happen again with some other object. It's
becoming a very common pattern in Rack to add various types of objects
to the environment.
Thanks,
Ryan
--
Dan Croak
http://thoughtbot.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Heroku group.
To post to this group, send email to heroku@googlegroups.com
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en
-~--~~~~--~~--~--~---
