As mentioned last week, my task was to employ a progress bar that implements SignalR. However, this approach revealed a bug that necessitates some debugging. Initially, upon integrating the SignalR method into the feature, I observed that the progress bar was not functioning properly. This prompted me to embark on a debugging session to identify the source of the mistake.
It turned out that the issue arose from me directly using instances injected through the constructor. This led to problems with transactions, as these instances might be associated with a different scope or not properly disposed of when the loop iterated over different input or command. To address this, I created a new scope and obtained instances of the contexts from that scope. This ensures that each transaction operates within the correct scope, preventing interference between transactions and potential issues with the lifetimes of the database contexts.
Subsequently, I focused on the main objective of the week, which was identifying a bug in the progress bar when users repeatedly clicked on a button requiring the usage of the progress bar. Initially, I assumed that the bug might originate from the context. However, after conducting multiple tests, all aspects within the context successfully passed data without encountering any errors. The issue, as it turned out, originated from the client side, specifically during the attempt to initiate the SignalR connection after the initial connection had already been established.
In my initial attempt to resolve the bug, I proposed a solution and discussed it with Mr. Peter. He then refined the code to implement a cleaner approach. As the week concluded, one lingering issue still required debugging: the progress did not display its progress but instead showed completion right away. I plan to address this in the upcoming week.