For RoR, see every method call, parameter and return value in production

prepend_around_action :callstacking_setup, if: -> { params[:debug] == '1' }

Once the request completes, the instrumented methods are removed to remove the performance overhead.

Imagine a million-line codebase. There are half a dozen suspicious methods with complex sets of if/else if/else statements. And each of those statements make subsequent method calls.

Determining that code path is a nightmare. Types won't save you.

That's not even mentioning the logic bugs you can spot more easily as well.

You have a new engineer. Point them to the Call Stacking dashboard.

"Here's a list of all of our endpoints for our application.

Click on a trace, and you can see the relevant methods for that endpoint and the context in which they are called."

This will get your new engineers up to speed, much quicker.

1) In a large-scale production scenario, you typically do not have the data, nor the interaction flow, to reproduce the bug locally. The idea is that you enable Call Stacking on the fly, when needed. Turn it off when not needed.

2) Having multiple runtime captures of the same endpoint across two different deployments or time periods allows you to quickly compare for logic or data changes (argument values and return values are visible).

3) Commenting on individual lines of execution allows for the team to have a specific discussion surrounding logic changes.

https://github.com/callstacking/callstacking-rails/blob/599d...

The goal is to quickly be able to see just the important, executed methods for a given request.

E.g. you may have a 2,000-line User model, but Call Stacking allows you to pinpoint, "Oh, only these three methods are actually being called during authentication. And here are the subsequent calls that those methods make. And here's where the logic change occurred."

You enable the instrumentation with a prepend_before_action,

e.g.

prepend_around_action :callstacking_setup, if: -> { params[:debug] == '1' }

When the request is completed, the instrumented methods are removed (thus removing the overhead).

You have to enable it judiciously. But for a problematic request, it will give the entire team a holistic view as to what is really happening for a given request. What methods are called, their calling parameters, and return values, all are given visibility.

You no longer have to reconstruct production scenarios piecemeal via the rails console.

When I was at ScoutAPM, we built a version of this that was stochastic instead of 100% predictable. We sampled the call stack every 10-50ms. Much lower overhead, and it caught the slower methods, which is quite helpful on its own, especially since slow behavior often isn't uniform, it happens on only a small handful of your biggest customers. But it certainly missed many fast executed methods.

Different approaches for sure, solve different issues.

On-premise is an option.

Not sure if Django could use it, but used an earlier version in Flask and Pyramid.

jim@callstacking.com

Manually reconstructing logistical errors based on a combination of user input and system data, are the most time-consuming issues to diagnose.

When your codebase is 500,000+ lines of code, which code paths are relevant for a given endpoint? What methods were called and under what context? How do we begin to reconstruct this bug?

These are the scenarios for which Call Stacking gives instant visibility to.

Typing is great, I am a fan. But seeing the values that are running through those types is not solved at compile time.