One of the most common issues when starting developing with ReactiveX is the issue that "nothing happens". There are several ways to avoid this, mostly by following the same development principles as any other piece of code:

• Write small parts of code and test them with unit tests. Whenever possible, follow test-driven development (TDD). It feels like a waste of time in the beginning, but from my experience it saves time as soon as the first development release is delivered.
• Develop the application step-by-step, with something that executes as early as possible. The initial implementation will be full of stubs, but they are already doing something. With each feature being implemented one after an other, finding an issue is easier.

Following these simple principles, you may still not make any progress. In this case, using the do_action operator is the only way to find the cause of the issue. Most of the time, the cause is an error that is not correctly handled or propagated. Typical culprits for these mistakes are the following:

• A missing on_error handler
• An exception being thrown in a function called by an operator (for instance, the function provided to the map operator)
• A missing scheduler

So, the first step is to read code changes for such potential errors. If no obvious mistake is found, then the do_action operator can be used to process a dichotomy search for the issue: add a trace handler (such as the one implemented in Chapter 10, Operators in RxPY) somewhere in the middle of the data flow. If no error is found, then go further into the data flow until the error is printed. If the error is found, then go backward between the current location and the preceding location in the data flow. This will lead to the origin of the error quite rapidly. It is important in this step to use a trace observer that logs all events: items, errors, and completion. This allows us to spot anything that is not normal behavior, either an error being raised, a malformed item, or an early completion.