Is there a way to configure stack so that everywhere it makes sense (i.e. all my code, but not the resolver packages), --trace is applied, so that I get a backtrace wherever I can?
Related
Two applications, one using Puma 4.3.4 and one using Puma 5.6.4, have both started failing with the same error:
Read error: #<NoMethodError: undefined method `each' for nil:NilClass>
Puma 5.6.4 gives no backtrace, but 4.3.4 indicates the problem is in /usr/local/bundle/gems/puma-4.3.4/lib/puma/server.rb:759 which is where Puma calls headers.each.
I’ve dropped into Pry here, and indeed headers is nil, but I can’t figure out why. This was all working quite happily earlier today!
If I inspect env I can see the request headers as expected, HTTP_HOST, HTTP_COOKIE and so on. So why is Puma failing to do whatever manipulation it normally does in preparation for handle_request?
These apps are part of a docker-compose setup which includes a proxy, but calling directly to the applications from within their own container gives the same problem, so it’s not the proxy stripping the headers (and anyway, they would be missing from env if so).
Upgrading Puma 4.3.4 to 5.6.4 doesn’t fix things, which also makes sense because the 5.6.4 app is broken too, and I assume it’s the same problem although without a backtrace I’m not sure how to verify that.
These are Sinatra apps, but I’m not sure that’s relevant – the request doesn’t seem to have reached that point in the stack when the error happens.
So this was in fact a bug in a custom middleware: when it failed under certain circumstances it returned nil rather than raising an exception.
This meant that none of the usual Sinatra or Sentry error-handling was triggered, and in turn they passed the empty result back up to Puma, which then choked as above.
The key thing was to make sure the middleware raised an exception under all circumstances where it cannot give a response!
I have a Chef cookbook (cookbook_alpha::default) that includes another cookbook (cookbook_bravo::default) using include_recipe 'cookbook_bravo::default'.
When I'm testing cookbook_alpha using ChefSpec, all of the resources in cookbook_alpha are shown and are tested. But the resources (files, templates, users etc) in cookbook_bravo show up as Untouched resources in cookbook_alpha test run. cookbook_bravo has it's own test suites and is covered adequately and I see no need to write duplicate, additional specs in cookbook_alpha simply to cover the resources from cookbook_bravo that are already tested.
Depending on your cookbook dependency manager (Berkshelf, Librarian, none) ChefSpec can determine, if a chef resource call is made outside or inside the current cookbook. (You still may have to stub calls to data bags and thinngs like file system checks in pre-conditionals (only_if, not_if)).
If you, for whatevery reasons, can't use any of the integration, you still can stub the include_recipe call as described in the ReadMe:
https://github.com/sethvargo/chefspec#include_recipe
hope this answers your question.
I am trying to use RSpec to functional test my REST apis.
The way I would LIKE it to work is using a CI build to build and deploy my application to a test server somewhere in the cloud and then have it kick off automated functional tests. But in order to properly do that, I need to be able to pass in the base url/domain for where the app was deployed. It will not be the same.
Everything I've found so far makes it seem like RSpec can't do this. Is there another way to do it if I can't pass in parameters on the command line? Or is RSpec not the right choice for this?
One way would be to bypass the call to rspec with something that accepts command line arguments and then initiate rspec in code. If you do not want to write your own binary for that, rake is capable of that too.
Look here for how to run rspec from code.
Another way would be setting an ENV variable when calling your test and preferably making it optional in the specs.
$> SPEC_URL=http://anotherhost:666 rspec
in code:
url = ENV['SPEC_URL'] || "http://localhost:4000"
I would suggest method two as it's the cleaner and easier approach in my opinion.
I use Go's native test facility (go test) to write a test. But when the test fails due to a bug in test code, I really can't debug it due to lack of stack trace or any other contextual informations.
And even, the test code needs one contextual object t, so it is not simple work running the test code in normal mode.
What is the best practice to debug test code?
You can log stack trace this way
t.Log(string(debug.Stack()))
Documentation is here https://golang.org/pkg/runtime/debug/#Stack
It is better than PrintStack because it doesn't interfere with regular test logs.
You can use t.Log() to log information about the test case -- go will show that output if the test case fails or if you run go test -v
You can also assert certain state within the test using panics -- if a test panics, you will see the trace in your console.
I don't know if you'd want to check in code with this in it, but for one-off debugging, PrintStack might help. http://golang.org/pkg/runtime/debug/#PrintStack
In my code that runs on eventmachine, how do I know if EventMachine::stop has been called?
I need this so that in my deferrable I do not log error messages that result solely from closing a connection and thus are not interesting from the operations stand point.
Is the only way to monkey patch the code?
If you have a peek at the source code for the pure-Ruby implementation of the EventMachine class in lib/em/pure_ruby.rb there's an instance variable defined called #stop_scheduled. It seems to be used internally to do exactly what you want to do - not perform some operations if we're currently shutting down.
Unfortunately this variable isn't exposed as part of the EventMachine API so you can't use it.
You might be stuck having to re-implement this kind of functionality yourself. Add a instance variable to the appropriate class(es)and have some guards around code that you don't want executed if a shutdown is in progress.