# How a Canceled Upload Reported Success The detailed anatomy of a software bug. - **Source:** [ProAndroidDev - Medium](https://brifing.si/source/d9553fa9-7b72-4b9b-bc73-c6bf9a40dd5f) - **Published:** 2026-08-31 - **Topic:** [Software & Engineering](https://brifing.si/c/engineering) - **Original article:** - **On Brifing:** https://brifing.si/s/8f3f20d5-8529-4090-85e1-69f4738fb26b ## Discovery of the Bug A developer team received a bug report in the demo version of their short-video SDK. When users canceled an upload, the progress bar stopped between 30% and 99%. However, the video appeared as processing in the grid. Upon refresh, the video disappeared. Despite never reaching the server, the app reported the upload as successful. ## Reproducing the Bug The bug could not be reproduced on demand but eventually showed up over time. This made detection and resolution challenging. The report sat in the backlog for a while before a solution was found. The fix was smaller than the bug itself. ## Upload Process In the SDK, uploads ran as tasks inside an executor. The base task class owned a simple contract. During upload, the task checked the cancellation flag and reported 'Done', 'Failed', or 'Canceled' accordingly. The grid listened to these notifications and displayed the appropriate state. ## Cancellation Operation The cancellation operation worked by setting a flag and interrupting the task. However, this contract failed twice. The cancellation interrupted the task but did not set the flag, causing the upload to be reported as successful. ## Cancellation Flag Error The cancellation flag was not set by the executor. This caused the flag to remain false during upload, leading to the upload being reported as successful. This resulted in a ghost entry appearing in the grid. ## Upload Library Inside the upload library, the transfer was driven by a polling loop. This loop had been in use for years and was not designed for cancellable operations. During cancellation, the channel threw an exception, but it was caught, and the operation continued normally. ## Exception Handling The polling loop treated a caught exception as a transient error and stopped looping. This caused the cancellation to go unnoticed. When the exception was caught, the upload appeared to complete normally. ## Flag Not Set During cancellation, the flag was not set. This caused the flag to remain false during upload, leading to the upload being reported as successful. This resulted in a ghost entry appearing in the grid. ## Combined Effect of the Bug When both errors combined, users received incorrect information. If the executor had set the flag, the upload would have been reported as canceled. If the polling loop had rethrown the exception, the upload would have been reported as canceled. However, both errors were open, causing the upload to be reported as successful. ## Resolution Process The solution involved one line of code and two checkpoints. The executor checked the flag before setting it. The polling loop rethrew the exception. This resolved the bug. The fix was smaller than the bug itself. ## Importance of the Bug This bug highlights an important point in software development. Cancellation operations must be handled carefully, and all layers must cooperate. Otherwise, users may receive incorrect information, leading to a loss of trust. ## Conclusion This bug highlights an important point in software development. Cancellation operations must be handled carefully, and all layers must cooperate. Otherwise, users may receive incorrect information, leading to a loss of trust. ## Sources covering this story - https://proandroiddev.com/one-flag-two-checkpoints-how-a-canceled-upload-reported-success-9f8d3e42f0cc?source=rss----c72404660798---4 — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._