I'm using heroku's rack-timeout gem, along with dynamic error pages as described here.
However, when timeout raises an exception, it get's routed as a 500 error rather than 503.
I could catch the exception with a rescue_from in my application controller and manually route to errors#503, but that would prevent plugins like Rollbar from recording the exception.
Is there a way to get the correct error page rendered and ensure plugins like Rollbar still get wind of the exception?
I ended up using the rambulance gem, which provides a simple configuration option to solve this:
# config/initializers/rambulance.rb
Rambulance.setup do |config|
config.rescue_responses = {
"Rack::Timeout::RequestTimeoutException" => :service_unavailable
}
end
The author has also written up some good reasons why not to use the approach I was previously using:
Remove custom errors page section from the guides
I know this is an old question, but there's no need to add a gem dependency for this.
rack-timeout raises an exception; the 500 results from that exception being unhandled. To handle that exception and get a 503 or whatever else you might want, add:
config.action_dispatch.rescue_responses["Rack::Timeout::RequestTimeoutException"] = :service_unavailable
to your application.rb file.
Related
I'm working on a Ruby software which may catch some errors (exceptions) and use Bugsnag to record the event in the Bugsnag logs.
For example, I may have something like this:
begin
[...snip...]
rescue StandardError => e
Bugsnag.notify(e)
end
What I'd like to be able to do is redirect the message logged by that line of code to my console. That way I could get it to my log file and then search on it and see what's before/after it and make sure things are working as expected.
Is there a way to setup Bugsnag to get such functionality?
I suggest using an On Error Callback. This callback will be executed for every handled and unhandled exception.
Bugsnag.configure do |config|
config.add_on_error(proc do |event|
# redirect message to your console here
end)
end
I started to build a website with padrino. At the moment the main class of my app is the simplest thing in the world:
class App < Padrino::Application
enable :sessions
get :index do
send_file 'public/view/index.html'
end
error 404 do
send_file 'public/view/errors/404.html'
end
end
So the views are simply htmls - the idea behind it is to use angularjs to render all the thingies provided by a rest api. I guess that's fairly standard.
My problem is - although it works fine for rendering the home page (localhost:3000/), the custom error doesn't work at all; let's say I try localhost:3000/test - the standard "Sinatra doesn’t know this ditty" page is rendered instead.
I'm running padrino 0.12.4 with WEBrick 1.3.1. What am I doing wrong here?
I believe what's going on here is that when you go to localhost:3000/test, your Sinatra app is looking for the "test" action under your App Controller. Obviously this action is not being found because it's not listed as a route! Therefore explicitly tell Sinatra to return a 404 page if the diddy wasn't found:
error Sinatra::NotFound do
content_type 'text/plain'
[404, 'Not Found']
end
I am trying to treat the invalid requests on my Laravel app, something like redirecting to the root will work just fine, but I can't manage to do it.
In the documentation and around stackoverflow I saw this is always the solution:
App::missing(function() {
# handle the error
});
I thought that would just go to the routes file but no. Then I saw in some post it should be in the app/start/global.php file but it still didn't work.
In the docs it says I can "register an error handle". Is that what I should do? What does this mean? What should I do?
Ultimately this can be put anywhere, but app/start/global.php is probably the best place for it.
App::missing(function($exception)
{
return Response::view('errors.missing', array(), 404);
});
Try putting this in there. In fact, if you've just setup a fresh installation, you should already have one there.
Here is how you can register an error handler, like so;
App::error(function(Exception $exception, $code)
{
//Now you can check for different exceptions and handle each on their own way.
}
This will be for PHP general Exception class which will make all exceptions go here, but you can change Exception to the specific Exception class of you own and handle it accordingly.
App::missing will generally be called when a page within your site has not been found, allowing you to show a default page for when users have found a non existing page. So if you are wanting to handle missing pages, use App::missing else use App::error.
I have a simple authentication code like on a zf2 application
$this->auth = new AuthenticationService(new Session($this->namespace));
and the external modules used are
ZendDeveloperTools
BjyProfiler
Everytime, I try to authenticate, like
$this->auth->authenticate($adapter)
I get a "Session validation failed" error message.
When I disable ZendDeveloperTools module, I do not get this error but couldnot fix. I also checked Zend\Session\Container Session validation failed exception — Object(Closure) ZF2, but I do not have anywhere on my code
$sharedEvents->attach('', '', .. )
as suggested by Crisp
i had a same problem.
Look at:
ZendDeveloperTools/Listener/EventLoggingListenerAggregate.php Line: 64
$events->attach($this->identifiers, '*', array($this,'onCollectEvent'),
Profiler::PRIORITY_EVENT_COLLECTOR);
i uncomment it, then i don't get the error.
Hope it was helpful.
I have an application that raises 404 Sinatra::NotFound errors on production when the route is missing.
However, the following test passes:
it 'should not raise error' do
expect{ get '/unknown_path' }.to_not raise_error
end
Why don't 404 Sinatra::NotFound errors get raised in the test?
The following does raise the error and cause the test to fail:
get '/unknown_path' do
raise 'error'
end
How to test for 404 Sinatra::NotFound errors?
The issue is that get /unknown_path' is not actually raising an error – it's only receiving a 404 request.
From Sinatra: README
The error handler is invoked any time an exception is raised from a route block or a filter. The exception object can be obtained from the sinatra.error Rack variable...
Your test is testing for an actual error (this is what raise_error does), while Sinatra is squashing the error – otherwise, every time someone 404'd the server would crash!
Check out the Sinatra testing guide for better direction on forming your tests. The basic idea is that using get ... in a test sets the last_response local variable, which can then be tested for equality, etc.
last_response has a status attribute, so (like was mentioned in another answer) you can just test to make sure that last_response.status equals 404.
Edit:
I wasn't really clear about this. In testing mode, the application does actually raise errors.
From Sinatra Settings
raise_errors
raise exceptions (will stop application). Enabled by default when environment is set to "test", disabled otherwise.
So you don't actually want to raise just any error, but raise Sinatra::NotFound.new("Not found!") to raise the specific type of error. The Sinatra::NotFound error will trigger the 404 handler. Sinatra Error Handling
Try this:
get '/unknown_path'
assert_equal last_response.status, 404