Calling a library function incorrectly means your stacktrace may not mention your code yet still be useful

This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the workflows category.

Last Updated: 2022-12-01

My rails program failed to run after I removed the second argument here

config.middleware.insert_after ActionDispatch::Static, Rack::LiveReload
# i.e. it became
# config.middleware.insert_after ActionDispatch::Static

When I booted, it gave an obscure stack trace:

/Users/jack/code/oxnotes4/vendor/bundle/ruby/2.6.0/gems/actionpack- `insert': wrong number of arguments (given 1, expected 2+) (ArgumentError)
    from /Users/jack/code/oxnotes4/vendor/bundle/ruby/2.6.0/gems/actionpack- `insert_after'
    from /Users/jack/code/oxnotes4/vendor/bundle/ruby/2.6.0/gems/railties- `block in merge_into'

This stack trace didn't mention any problematic non-library file (i.e. nothing from my code), so I assumed I was driving blind. This was premature. I should have read past the top-entry of the stack trace and seen the following entries:

Had I grepped for insert_after through the codebase, I would have come across my issue sooner and realized that my recent change introduced the error.


When debugging using stack-traces, go beyond the first line (it's not always reliable)

Be careful to connect the dots when calling built-in methods from your framework incorrectly (vs. seeing a method you defined yourself). In general, bugs attributable to your calling a library function incorrectly will show up as being "within" the library code (vs. your own code) so you might wrongly assume the stack-trace has nothing to tell you.