The reactive programming paradigm helps developers write programs that maximize computation throughput by utilizing non-blocking operations. However, developers often write reactive programs incorrectly, even with dedicated libraries and frameworks. Given the growing popularity of reactive programming, it is important to understand the debugging practice of reactive applications. In this work, we analyze issues reported in reactive applications and explore their corresponding fixes. Our investigation results reveal that (1) developers often do not fix or ignore reactiveness bugs as compared to other types of bugs, and (2) this tendency is most pronounced for blocking-call bugs – the bugs that block the execution of the program to simply wait for the operations (typically I/O operations) to finish, wasting CPU and memory resources. To improve the debugging practice of those blocking-call bugs, we develop a pattern-based proactive program repair technique and obtain 30 patches, which we submit to the original developers. In addition, we hypothesize that the low patch acceptance rate for reactiveness bugs is due to the difficulty of assessing the patches. This is in contrast to functionality bugs, where the correctness of the patches can be evaluated by running test cases. To assess our hypothesis, we split our patches into two groups: one with performance improvement evidence and the other without. It turns out that the patches are more likely to be accepted when performance improvement evidence is provided.