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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
