https://bugs.kde.org/show_bug.cgi?id=480391
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WAITINGFORINFO |NOT A BUG Status|NEEDSINFO |RESOLVED --- Comment #8 from [email protected] --- Just to recap; 1. The title of this report claims flatpak updates freeze if you disconnect the WI-FI during a download. I don't understand why you would do this in the first place? You wrote in the summary that it is easier to replicate on slower connections and you also wrote in step 1 to accumulate lots of updates. --There are multiple TCP/IP sockets that will need to renegotiate after losing & regaining connection. This is always going to casue *some* sort of a delay in *any* software. This problem is amplified on slower connections. On top of disconnecting twice, you clicked cancel twice. This will also cause each TCP/IP socket to terminate its connection to flathub, using some CPU cycles, causing some delay etc. 2. The video shows you disconnecting and then clicking cancel, *twice.* You then replied to me that the bug is actually that the cancel button does nothing after changing WI-FI, despite the fact that by the end of the video, all progress bars seem to disappear and Discover reports the same amoint of updates available as the start of the video. 3. You then replied to me that the 25 updates left at the end of the clip is a graphical bug because you changed the view to the Heroic Games Launcher. You later clarified that any view change will cause this. If what you mean is the 25 updates in the final few frames of the video are actually there, waiting to be downloaded and installed, then the cancel button worked as intended. I'm not at all convinced this is a bug in discover. Purposefully disconnecting from the network during an upgrade and then clicking cancel in discover is not a bug in KDE software, it is user error. Sorry, but I'm closing this. -- You are receiving this mail because: You are watching all bug changes.
