Matt's Tidbits #55 - Strange Breakpoint behavior with Rx schedulers
Tags: mattstidbits, kotlin, rxjava, junit
Published: 2020-02-11 16:55:34

[Last time I shared a story (and some lessons learned) to share around a recent website deployment.](https://medium.com/@matthew.b.groves/matts-tidbits-54-caches-deployments-and-it-oh-my-6245c41a7b61) This week, I have a story about some odd breakpoint behavior.

Recently I was debugging a unit test and was very puzzled because one of my breakpoints was not being hit. The breakpoint was in Kotlin code, inside of a lambda that was being called as a result of a Rx subscription (if you've worked with code like this, you probably understand why I was trying to debug it!)

I'm no stranger to having issues with breakpoints in Kotlin, so I quickly ticked through my mental list of known issues (and previous tidbits, [especially #14](https://medium.com/@matthew.b.groves/matts-tidbits-14-debugging-the-debugger-a-tale-of-broken-breakpoints-1eac8cc3a3da)) and first checked that the breakpoint was actually being set at runtime. I quickly that the breakpoint was not receiving the check mark that it should have been. This seemed like a perfectly valid line of code, but just on a whim I tried some of my other tricks - converting unit tests written with Kotlin's `` ` `` syntax to use underscores instead. That unfortunately didn't help either.

So, I started experimenting to see if any breakpoints would work, and finally found that one did - I just had to set it much earlier in the program. What I found next really startled me - what I discovered almost by accident was that the breakpoint I was most interested in had now received the checkmark - but only once the program was paused. I tested this a few more times, and verified that I wasn't crazy - as long as I had a breakpoint earlier on in the program, the breakpoint I wanted would successfully pause. If I took out the earlier breakpoint though, the program would never stop on my breakpoint.

This smelled like some kind of race condition to me - adding a delay (in this case, pausing the program before that breakpoint was evaluated) caused something else to happen/load which resulted in the expected behavior. I wasn't sure why this was happening, but drawing on my experience with debugging complex/unknown problems ([see tidbit #35](https://medium.com/@matthew.b.groves/matts-tidbits-35-a-strategy-for-debugging-complex-unit-test-failures-1d4097a0903e)) - I started by switching to an older version of the code and testing this behavior there.

I found that in the older version of code my breakpoint worked fine. So, something had changed that was causing this to happen. As part of my current work I had just finished a large code merge, so I decided to re-review what I had done. In doing that, I discovered the crucial missing piece - the way that RxJava schedulers were being set up (specifically for tests) had changed, and I had done the merge incorrectly. What I had written compiled just fine, but I had neglected to notice that some of the other auto-merged code written by other members of my team set things up in a different way than I had been doing on my branch.

Upon correcting that error, I was thrilled to discover that the program now paused on my breakpoint as expected!

To recap, if you run into a case where a breakpoint in a unit test isn't working, you should:
1. Check that the breakpoint has the checkmark icon at runtime - if not, your program won't pause.
2. If it doesn't have the checkmark, and you're positive that it should (and you've tried the steps from Tidbit #14 above to rule out issues with Android Studio/Kotlin), try adding a breakpoint somewhere early on in the execution of your program - at a point before your other one should be hit.
3. If this 2nd step causes your breakpoint to receive the checkmark, then check whether that unit test now passes - it's possible it will!
4. If the 3rd step happens, then you definitely have an issue with your RxJava scheduler configuration. Double-check that code, and you will likely find the issue!

I hope you learned something that helps you the next time you're debugging some strange unit test failures. Please share your strangest debugging horror story in the comments below - I'd love to hear from you! And, please follow me on Medium if you're interested in being notified of future tidbits.

Interested in joining the awesome team here at Intrepid? [We're hiring!](https://www.intrepid.io/careers)

*This tidbit was discovered on January 22, 2020.*