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-6.0.2.1/lib/action_dispatch/middleware/stack.rb:99:in `insert': wrong number of arguments (given 1, expected 2+) (ArgumentError)
    from /Users/jack/code/oxnotes4/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.2.1/lib/action_dispatch/middleware/stack.rb:108:in `insert_after'
    from /Users/jack/code/oxnotes4/vendor/bundle/ruby/2.6.0/gems/railties-6.0.2.1/lib/rails/configuration.rb:71:in `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.

Lessons

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.