Backup ZIP files were being deleted using a background thread that waits a fixed amount of time before removing the file:
time.sleep(20)
os.remove(self.zippedFile)
This assumes that every download finishes within 20 seconds, which is unreliable.
This creates a race condition:
- Slow networks or large backups can result in the file being deleted while the download is still in progress, producing corrupted ZIP files.
- Fast downloads leave temporary files unnecessarily on disk.
- Cleanup timing becomes non-deterministic and dependent on network conditions.
While investigating this logic, the /myfunc endpoint was also found to instantiate the Download thread with missing constructor arguments, causing a guaranteed TypeError at runtime. The Download class expects both a request object and a zippedFile path, but the route only passes a copied request object, meaning the thread cannot be constructed successfully and the endpoint will always fail when invoked.
Additionally, the route does not appear to participate in the current backup workflow and relies on the same time-based cleanup mechanism described above. Since no ZIP file is created or managed within this handler, the cleanup thread has no valid file target, making the logic inconsistent with the intended design. This strongly suggests the endpoint is leftover or experimental code that was never fully integrated.
Backup ZIP files were being deleted using a background thread that waits a fixed amount of time before removing the file:
This assumes that every download finishes within 20 seconds, which is unreliable.
This creates a race condition:
While investigating this logic, the
/myfuncendpoint was also found to instantiate theDownloadthread with missing constructor arguments, causing a guaranteedTypeErrorat runtime. The Download class expects both a request object and a zippedFile path, but the route only passes a copied request object, meaning the thread cannot be constructed successfully and the endpoint will always fail when invoked.Additionally, the route does not appear to participate in the current backup workflow and relies on the same time-based cleanup mechanism described above. Since no ZIP file is created or managed within this handler, the cleanup thread has no valid file target, making the logic inconsistent with the intended design. This strongly suggests the endpoint is leftover or experimental code that was never fully integrated.