Table of Contents
Get the latest news

Making Rookout’s Breakpoints Even More Non-Breaking

Oded Keret | VP of Product

5 minutes

Table of Contents

Stop me if you’ve heard this one before.

You’re debugging a local app using your favourite IDE. You set a breakpoint, the code stops, and you look at the local variables. You get a sense of what’s going on, what has happened, and what should happen next. Then, you step forward to the next line of code, and the one after that, and the one after that, and the one after that is invoking a function, so you step in again…

If at first you don’t succeed, step in again

Well, at least, you try to step in. But the function you are invoking came from a third party class, and you don’t have the source files. Or maybe it was compiled or transpiled in a way that doesn’t allow debugging. Maybe you’re missing some of the debug information files, or they were generated from a different version of your code.

In the happy flow, 1 app instance is connected, and the breakpoint is green and “Active”. Let the data flow!

The best-case scenario here is that you find the debug information or source files, and try again. Maybe you even rebuild the entire project to get the full debug data. The worst-case scenario is that you are just unable to debug.

The bigger problem of data availability

Of course, the above is a simplified and local version of the bigger problem that we are trying to solve with Rookout. We want to make sure you can always get the data you need so that you can always get full visibility into your code. And like many other things, this challenge becomes even bigger when you are building a cloud-native app; when your app is already running in staging and prod; or when you’re looking at a huge monolith that someone else wrote.

running in staging and prod
Hmm. This is interesting. Why do I see two apps when I was expecting one? And why is one of them grey and marked as “Pending?” Better read those troubleshooting tips…

In those cases, there are even more things that can stop you from seeing the data you need. For a start, there could be multiple instances of the app you are trying to debug. And each instance could have a different version of the code or a different configuration. Some of these instances may not yet be up at the time of setting the breakpoint, and others may be torn down after it’s been set.

So which instances should Rookout fetch data from? And which instances may require your or your DevOps team’s attention in order to guarantee observability?

Breakpoint status breakdown capabilities

To address these concerns, we have invested significantly in improving our Breakpoint Status Breakdown capabilities.

Breakpoint status breakdown - Rookout
OK, it looks like something, somewhere, went terribly wrong. And that is why I’m not getting the log lines and debug snapshots I was looking for. Better fetch my DevOps expert and check why this version is deployed in both Staging and Prod and why my Rookout-Slack integration is misconfigured.

Now, expanding the Breakpoint Status pane will show you the following:

  1. How many instances of your application has the Breakpoint been applied to?
  2. Did Rookout fail to apply Breakpoints to some of these instances, for example, because they are running a code version that does not match?
  3. Which instances have such problems, and how do I spot them?

With this information, we hope you will gain some insight into your app even before you start getting debug messages or log lines streamed into your observability pipeline. For example, you may discover that you see more instances or fewer instances than you expected. Or you may find that some instances are not deployed in the right environment, or that they aren’t using the right code version.

In fact, as we rolled out this functionality, we have learned that some of our customers even use this ability to keep an eye on their CI/CD flows, giving their DevOps team a quick health check of their current deployment.

giving their DevOps team a quick health check
Ah, this explains everything. My Rookout tags and filters were not configured correctly, and Rookout is trying to apply the same breakpoint to two apps – one written in Java, and one written in Node. Better clean this up so I can keep working quietly.

BP status breakdown for Rookout deployment

The breakpoint status should also allow you to troubleshoot your Rookout deployment. If you are missing the debug messages and log lines you were expecting, the breakpoint status indicator may hint at the underlying reason.

In some cases, we learn that the Rookout SDK was just not installed on the relevant instances, or that it cannot reach Rookout due to network connectivity issues. In other cases, we learn that specific frameworks behave differently than expected when we baked them into our app. If you are using Python forking servers, or Node.js transpiling frameworks, you may have already faced these challenges.

And as happens quite too often, Randall released this comic just as we were working on this blog post. We feel it’s a painfully true representation of us trying to write an error or warning message you should not have faced when troubleshooting a sneaky breakpoint. If you do see this error message in Rookout, please reach out to and let us know.

We hope the new breakpoint status breakdown view will help you understand what’s going on when you set a Non-Breaking Breakpoint, and that in turn, will help you gain the observability you need. If you have any questions or suggestions, be sure to give us a shout!

Rookout Sandbox

No registration needed

Play Now