SUMMARY Demonstrative video: https://youtu.be/_We4wPeVtGU Replicated on SteamOS 3.5.13 When you have a lot of flatpak updates in Discover, it is possible to stall the update process by chancing the wifi connection during download. It's easier to replicate on slower connections. I don't have a way to easily test this with stable or beta releases so I don't know if it's fixed already STEPS TO REPRODUCE 1. Accumulate lots of updates 2. Start the update process 3. Change your wifi connection OBSERVED RESULT Most of the updates will freeze EXPECTED RESULT The update should continue where it left off SOFTWARE/OS VERSIONS Linux: SteamOS 3.5.13 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.9
I'm not quite sure how exactly this can be considered a bug. In the video, you start the update, the update starts, you change WI-FI, click cancel, switch WI-FI again and then click cancel again.
The bug is in the fact that the cancel button does absolutely nothing after changing the wifi
(In reply to Antti Savolainen from comment #2) > The bug is in the fact that the cancel button does absolutely nothing after > changing the wifi But that is not what you reported, and it is not what the video shows. In the original bug report, you wrote; "STEPS TO REPRODUCE 1. Accumulate lots of updates 2. Start the update process 3. Change your wifi connection OBSERVED RESULT Most of the updates will freeze EXPECTED RESULT The update should continue where it left off" The updates are not going to continue where they left off because you clicked cancel on two separate occasions, after changing the WI-FI connection, mid-update, twice. You're now saying the bug is actually that cancelling the update does nothing? Because the start of the video shows 25 updates available. As soon as you click 'update all', the progress bars begin to fill up, as expected - the update starts. In the final few frames of the video, the progress bars have disappeared and Discover still reports 25 updates available. I see no bug here.
> In the final few frames of the video, the progress bars > have disappeared and Discover still reports 25 updates available. I see no > bug here. That's a graphical bug because I changed the view to the Heroic Games Launcher store page.
I went to test this since it's been almost 2 years since I reported this and it still happens
(In reply to Antti Savolainen from comment #4) > > In the final few frames of the video, the progress bars > > have disappeared and Discover still reports 25 updates available. I see no > > bug here. > > That's a graphical bug because I changed the view to the Heroic Games > Launcher store page. Can you please clarify on what exactly you mean by "changed the view"? (I'm not familiar with SteamOS or Steam Deck or whatever it's called). Are you saying that the Heroic Games Launcher caused or is causing a graphical glitch in Discover? Can you please post your system specs here. I'm assuming you're using a more recent version of KDE Plasma than the one you reported when opening this bug. Thanks.
I did the restest in SteamOS. I don't have enough updates lined up in my laptop to test this in an up-to-date system > Are you saying that the Heroic Games Launcher caused or is causing a graphical glitch in Discover? No, any view change should do it. HGL just happened to be the one I visited in that video clip. Here's the SteamOS specs Operating System: SteamOS 3.7.16 Build: 20250929.1 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.11.11-valve24-2-neptune-611-gfd0dd251480d (64-bit) Graphics Platform: X11 Partition: B Processors: 8 × AMD Custom APU 0932 Memory: 14.5 GiB of RAM Graphics Processor: AMD Custom GPU 0932 Manufacturer: Valve Product Name: Galileo System Version: 1
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.
Freeze was likely a poor choice of words, but it's ok. i understand.