For me it doesn't get stuck, but it just takes a lot of time and doesn't explain what it's doing, what servers is contacting, what are their pings, what are their download speeds.
I think it was made with the idea of noobs feeling fine by hiding every kind of useful information.
Feels very similar to Windows updater that hides everything.
A few days ago one of my DNS servers was responding very slow and I had not idea until I got the same problem in Firefox too, as Discover is always very slow on Debian, but I can't say it was any difference with it on KDE Neon.

I'm also experiencing this issue since plasma desktop update to 6.3.  The update to 6.3.1 does not resolve this issue.

I actually git past this now.
I deleted the configuration file for discover from .config in my homedir and then it just worked

(In reply to Jarl Gjessing from comment #3)
> I actually git past this now.
> I deleted the configuration file for discover from .config in my homedir and
> then it just worked

I tried this too but it didn't work.

I ran pkmon when Discover was fetching.  It looks like it finalizes without ever returning (using g_task_return_*())

Transactions:
 [none]
daemon connected=1
network status=online
Transactions:
 1      /157867_accbccec
/157867_accbccec        allow_cancel 1
/157867_accbccec        percentage   99
/157867_accbccec        role         refresh-cache
/157867_accbccec        sender       /usr/bin/plasma-discover
/157867_accbccec        status       running

(pkmon:3474776): GLib-GIO-CRITICAL **: 07:02:53.732: GTask 0x56e851ba5340 (source object: 0x56e851ba6200, source tag: 0x7d52be0e26c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program.
updates-changed
Transactions:
 1      /157867_accbccec
 2      /157868_aecaeacb
/157868_aecaeacb        allow_cancel 1
/157868_aecaeacb        percentage   -1
/157868_aecaeacb        role         get-updates
/157868_aecaeacb        sender       /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier
/157868_aecaeacb        status       wait

(pkmon:3474776): GLib-GIO-CRITICAL **: 07:03:04.254: GTask 0x56e851bae1e0 (source object: 0x56e851ba6200, source tag: 0x7d52be0e26c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program.
Transactions:
 1      /157868_aecaeacb
updates-changed
Transactions:
 1      /157868_aecaeacb
 2      /157869_cedababa
/157869_cedababa        allow_cancel 1
/157869_cedababa        percentage   -1
/157869_cedababa        role         get-updates
/157869_cedababa        sender       /usr/bin/plasma-discover
/157869_cedababa        status       wait

(pkmon:3474776): GLib-GIO-CRITICAL **: 07:03:05.141: GTask 0x56e851bae4d0 (source object: 0x56e851ba6200, source tag: 0x7d52be0e26c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program.
Transactions:
 1      /157868_aecaeacb
 2      /157869_cedababa
 3      /157870_eecdeced
/157870_eecdeced        allow_cancel 1
/157870_eecdeced        percentage   -1
/157870_eecdeced        role         get-updates
/157870_eecdeced        sender       /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier
/157870_eecdeced        status       wait

(pkmon:3474776): GLib-GIO-CRITICAL **: 07:03:05.403: GTask 0x56e851bae1e0 (source object: 0x56e851ba6200, source tag: 0x7d52be0e26c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program.
Transactions:
 1      /157869_cedababa
 2      /157870_eecdeced
Transactions:
 1      /157870_eecdeced
Transactions:
 [none]

(In reply to Brian Wright from comment #2)
> I'm also experiencing this issue since plasma desktop update to 6.3.  The
> update to 6.3.1 does not resolve this issue.

same here. pkcon update *does* work.  Discover instead is stuck on "Fetching" for hours but never finishes with that.  reinstalled, deleted all caches .. to no avail. Since 6.3

I have a slight supicion it can be related to KNewStuff updates not ending, or not signaling when it ends.

Could you please try running from the command line:
plasma-discover --backends=flatpak,packagekit --mode=Update

(In reply to Ismael Asensio from comment #7)
> I have a slight supicion it can be related to KNewStuff updates not ending,
> or not signaling when it ends.
> 
> Could you please try running from the command line:
> plasma-discover --backends=flatpak,packagekit --mode=Update

$ time plasma-discover --backends=flatpak,packagekit --mode=Update
org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: true
adding empty sources model QStandardItemModel(0x6501bc8e4d00)
qrc:/qt/qml/org/kde/discover/qml/LoadingPage.qml:3:1: QML LoadingPage: Created graphical object was not placed in the graphics scene.
QObject::startTimer: Timers cannot have negative intervals
qrc:/qt/qml/org/kde/discover/qml/UpdatesPage.qml:11:1: QML UpdatesPage: Created graphical object was not placed in the graphics scene.
qrc:/qt/qml/org/kde/discover/qml/UpdatesPage.qml:40:5: QML OverlaySheet: Binding loop detected for property "implicitHeight":
file:///usr/lib/x86_64-linux-gnu/qt6/qml/org/kde/kirigami/templates/OverlaySheet.qml:132:5
^C

real    0m20,927s
user    0m11,785s
sys     0m1,914s

(In reply to Ismael Asensio from comment #7)
> I have a slight supicion it can be related to KNewStuff updates not ending,
> or not signaling when it ends.
> 
> Could you please try running from the command line:
> plasma-discover --backends=flatpak,packagekit --mode=Update

and it *shows* the Updates after a couple of seconds as usual

I confirm that running from the command line shows a normal behavior, while running from the GUI results in "eternal" fetching.
I would also like to point out that not all computers are affected - for example, my desktop (~ 10 years old) has the problem described above since a coouple of weeks, while my laptop (2024 model) does not, although they both run KDE 6.3.2 and should have (for all I know) the same configuration.

Also, disconnecting and reconnecting the network can occasionally result in the "eternal fetching" to stop and show results, but not always (sometimes you have to repeat this 2-3 or more times). On the other hand, deleting the Discover configuration file (as suggested in comment 3 above) had no effect for me.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/1051

*** Bug 500722 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/1053

Git commit b1b171f7c51d0aec9cd63953b83719a7c773fd77 by Aleix Pol Gonzalez.
Committed on 10/03/2025 at 01:28.
Pushed by apol into branch 'master'.

kns: Ensure we deactivate the updater when the backend gets invalidated

Otherwise it just gets stuck ad eternum.

FIXED-IN: 6.3.3

M  +7    -0    libdiscover/backends/KNSBackend/KNSBackend.cpp
M  +7    -0    libdiscover/resources/AbstractResourcesBackend.h
M  +10   -1    libdiscover/resources/StandardBackendUpdater.cpp

https://invent.kde.org/plasma/discover/-/commit/b1b171f7c51d0aec9cd63953b83719a7c773fd77

Git commit f7aec1dca82865945af2638dd40b645831181905 by Aleix Pol Gonzalez.
Committed on 10/03/2025 at 01:36.
Pushed by apol into branch 'Plasma/6.3'.

kns: Ensure we deactivate the updater when the backend gets invalidated

Otherwise it just gets stuck ad eternum.

FIXED-IN: 6.3.3


(cherry picked from commit b1b171f7c51d0aec9cd63953b83719a7c773fd77)

M  +7    -0    libdiscover/backends/KNSBackend/KNSBackend.cpp
M  +7    -0    libdiscover/resources/AbstractResourcesBackend.h
M  +10   -1    libdiscover/resources/StandardBackendUpdater.cpp

https://invent.kde.org/plasma/discover/-/commit/f7aec1dca82865945af2638dd40b645831181905

now in:  https://kde.org/announcements/changelogs/plasma/6/6.3.2-6.3.3/

congrats the the devs and thanks to all involved!

The bug is actually still occurring some time or has returned.
This actually can be fixed in a proper way if the developers added a setting to not auto-update apt every time Discover is launched. Just add a toggle switch so the user can choose.