https://bugs.kde.org/show_bug.cgi?id=527475
Bug ID: 527475
Summary: Discover 6.8.0: Snap application unexpectedly removed
while searching, without explicit confirmation
Classification: Applications
Product: Discover
Version First 6.8.0
Reported In:
Platform: Neon
OS: Linux
Status: REPORTED
Severity: major
Priority: NOR
Component: Snap Backend
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Created attachment 197399
--> https://bugs.kde.org/attachment.cgi?id=197399&action=edit
Logs
## Summary
On 20 October 2026, the WhatsDesk Snap application was unexpectedly removed
from my system while I was searching for it in KDE Discover 6.8.0.
**I did not click Remove, Uninstall, or any equivalent action. I did not
confirm or authorise the removal of WhatsDesk.**
I had opened Discover specifically to locate WhatsDesk following an application
crash. Despite WhatsDesk being installed locally, Discover reported that the
application was unavailable in the configured repositories. I searched for it
both before and after its removal.
Subsequent investigation revealed that KDE Discover logged a
`QSnapdRemoveRequest` warning just **5.434 milliseconds** before snapd recorded
the creation of a transaction to remove WhatsDesk.
This is an unusually close correlation between Discover handling a Snap removal
request and snapd beginning the actual removal operation.
Although the available logs cannot conclusively identify which process
initiated the removal, the evidence strongly suggests Discover was involved.
I am reporting this with **Major severity** because an application being
removed without an explicit user request is potentially a serious
package-management issue. This has been observed once and has not yet been
reproduced.
## Steps leading to the issue
1. WhatsDesk was installed locally as a Snap application.
2. WhatsDesk crashed after failing to initialise its Wayland display.
3. I opened KDE Discover to find the application, intending to uninstall it.
4. I searched for WhatsDesk, but Discover reported that it was not available in
the configured repositories.
5. I did not find an entry through which I could initiate removal.
6. **I did not click an uninstall button or approve any removal operation.**
7. WhatsDesk nevertheless disappeared from the system while Discover was
running.
8. Investigation of the system journal and snapd transaction history confirmed
that WhatsDesk had been removed.
The issue has not been reproduced.
## Expected behaviour
Discover should not remove installed applications unless the user explicitly
requests their removal.
Searching for an application, including one unavailable in the remote
catalogue, must not trigger an uninstall operation.
Locally installed Snap applications should ideally remain visible and
manageable even if their store listing is unavailable.
## Actual behaviour
WhatsDesk was removed without any explicit uninstall action or confirmation
from me.
The following events were recorded on 20 October 2026 (BST):
**10:12:54.485273 — KDE Discover launched**
```text
systemd[3501]: Started
[email protected] - Discover -
Software Centre.
```
**10:13:04.950013 — Discover logs a Snap removal-request warning**
```text
plasma-discover[60535]: QObject::connect(QSnapdRemoveRequest, SnapTransaction):
signal not found
```
**10:13:04.955447 — Snapd creates the WhatsDesk removal transaction**
```text
Change ID: 83
Kind: remove-snap
Snap: whatsdesk
Spawn-time: 2026-10-20T10:13:04.955447032+01:00
Ready-time: 2026-10-20T10:13:12.445277359+01:00
Status: Done
```
**The interval between Discover's warning and the creation of snapd's removal
transaction is approximately 5.434 milliseconds.**
This interval is not being presented as the time available for user
interaction. Rather, it demonstrates that Discover's removal-request handling
and snapd's removal transaction occurred almost simultaneously.
The Snap transaction completed successfully, removing WhatsDesk revisions 42
and 43.
## Why this is concerning
The particularly concerning aspect is that **no removal action was initiated by
me**.
I was attempting to find WhatsDesk in Discover, but Discover did not provide a
searchable result for the installed application.
Despite this, Discover logged a warning involving `QSnapdRemoveRequest`,
immediately followed by snapd registering a removal transaction for that
application.
The warning itself does not establish the reason for the removal. However, the
timing warrants investigation into whether Discover can inadvertently create or
submit a Snap removal request without explicit user interaction.
If this behaviour can affect other installed Snap applications, it could
potentially result in unexpected application removal and associated disruption
or data loss.
No application data loss has been confirmed in this incident.
## System information
- Distribution: KDE neon User Edition, Ubuntu 24.04 Noble base
- Desktop environment: KDE Plasma 6.8.0
- Display server: Wayland
- KDE Discover: 6.8.0
- plasma-discover-backend-snap: 6.8.0
- libsnapd-qt6-2-1: 1.67
- snapd: 2.77.1
- Affected application: WhatsDesk
- Removed Snap revisions: 42 and 43
- Snap transaction ID: 83
## Additional investigation
The following checks have been performed:
- Confirmed that WhatsDesk is no longer installed using `snap list`.
- Confirmed successful removal through `snap changes`, `snap tasks 83` and the
snapd API.
- Verified that the Discover Snap backend plugin (`snap-backend.so`) exists and
loads successfully.
- Confirmed that Discover can locate another installed Snap application,
Notepad++.
- Examined shell history; no removal command preceded the transaction.
- Correlated Discover's journal messages with the snapd transaction timestamps.
- Confirmed that the application was searched for both before and after
removal.
The full journal excerpts and snapd transaction details are attached.
## Request for investigation
Could the maintainers investigate the code path responsible for creating
`QSnapdRemoveRequest` and its associated `SnapTransaction` in Discover 6.8.0?
In particular, I would be interested in understanding:
1. Under what circumstances can Discover construct a Snap removal transaction?
2. Could a removal request be initiated without an explicit user action?
3. Could a failed Qt signal connection affect the visibility or handling of a
removal transaction?
4. Could an installed Snap application missing from Discover's catalogue
trigger an unexpected removal or state-management error?
I appreciate that this is currently a single incident and that the logs do not
conclusively prove Discover initiated the removal.
Nevertheless, the combination of an unauthorised removal, an application absent
from Discover's search results, and the approximately 5.4-millisecond
correlation between Discover's removal-request warning and snapd's removal
transaction seems sufficiently unusual to warrant investigation.
--
You are receiving this mail because:
You are watching all bug changes.
