During the past week, my primary goal was to address various bugs in the modified section of the application where the progress bar with SignalR had been recently implemented. As mentioned in my previous blog, a critical issue arose when attempting to save changes after the loading bar reached 100 of saving batch data, triggering an error message stating “batch too large.” After thorough debugging, it was identified that the problem originated from Cassandra. To resolve this, Mr. Peter showed me a temporary solution by directly overwriting the save changes in the database. The rationale behind this approach is the potential removal of Cassandra usage in the future.<\/p>\n\n\n\n
The next bug involved the progress bar not advancing and continuously displaying “Queue (0\/0)” after the user clicked ‘cancel’ during a previous process. This issue was rectified by making minor changes to the conditional statements. However, the most time-consuming bug to diagnose was an unresponsive UI on the cancel button during data generation. This occurred after the user initiated another process in the same section. Initially, a thread-related problem was suspected, but even after converting certain parts of the code to asynchronous, the issue persisted. <\/p>\n\n\n\n
Towards the end of the week, I inserted a line of code to monitor the changes in the progress bar and its GUID. It became evident that with each cancellation, multiple GUIDs were managing the progress in the subsequent progress bar. My initial hypothesis was that the cancellation process might not be completed and the multiplication of GUID during each cancellation could be the root cause of the lagging issue. Unfortunately, by the end of the week, I was unable to resolve this particular section of the code.<\/p>\n","protected":false},"excerpt":{"rendered":"
During the past week, my primary goal was to address various bugs in the modified section of the application where the progress bar with SignalR had been recently implemented. As mentioned in my previous blog, a critical issue arose when attempting to save changes after the loading bar reached 100 of saving batch data, triggering … <\/p>\n