__FILEPROVIDER_BAD_ITEM_MISSING_IDENTIFIER__ Crash

### ⚠️ Before submitting, please verify the following: ⚠️

- [x] This is a **bug**, not a question or a configuration issue.
- [x] This issue is **not** already reported on Github (I have searched for it).
- [x] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [x] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### Bug description

## Summary

Nextcloud Desktop's macOS `FileProviderExt` extension repeatedly crashes with
a `SIGABRT` inside Apple's own File Provider framework
(`__FILEPROVIDER_BAD_ITEM_MISSING_IDENTIFIER__` /
`__FILEPROVIDER_BAD_ITEM__`), triggered while reconstructing an `FPItem` from
one of the client's own locally-tracked items. This happened during a large
(5 GiB, ~1,050 file) sync with Virtual Files/File Provider mode enabled, and
was severe enough at one point to crash-loop continuously (a new process
every 30-60 seconds) until the account's local File Provider domain state was
reset.

## Crash signature

Three separate crash reports captured, same signature every time:

```
Exception: SIGABRT
__pthread_kill
pthread_kill
abort
__assert_rtn
__FILEPROVIDER_BAD_ITEM_MISSING_IDENTIFIER__
__FILEPROVIDER_BAD_ITEM__
-[FPItem initWithVendorItem:provider:domain:spotlightDomainIdentifier:extensionCapabilities:useFPFS:]
-[FPXDomainContext itemFromVendorItem:]
-[FPXChangesObserver didUpdateItems:] (occurrences 2 and 3)
__63-[FPXExtensionContext itemForItemID:request:completionHandler:]_block_invoke.380 (occurrence 1)
```

- Occurrence 1: `2026-08-01 20:46:41 +0200`, incident id
`0FEDF7DB-B482-4C5E-88ED-2466B347507C`.
- Occurrence 2: `2026-08-01 22:27:27 +0200`, incident id
`603BAD58-F147-4AB9-B4E8-ED7F30EC3A74`.
- Occurrence 3: `2026-08-02 10:29:30 +0200`, incident id
`7DF5D0AE-C99F-4CB8-AE49-4F6AED005AA1` — notably, this one happened on a
**freshly reset File Provider domain with a freshly re-copied local corpus**
(not accumulated state from repeated resets), see below.

Both crashes happen while the extension is servicing a normal File Provider
callback (an item lookup, or reacting to a changes-observer update) and
Apple's own framework code asserts that the vendor item being converted into
an `FPItem` is missing a required identifier. This is an assertion inside
`FileProvider.framework`/`FileProviderUI` territory (`__FILEPROVIDER_BAD_ITEM*`
symbols are Apple's, not Nextcloud's), which means the *proximate* trigger is
Apple's framework refusing a malformed item — but the item comes from
Nextcloud's own local tracking database (a Realm-backed store; a
"Realm notification listener" thread is present in both crash reports), so
the root cause is presumably a record in that local database that's missing
a field the framework expects.

### Steps to reproduce

No minimal repro found. Occurred twice during a ~5 GiB / ~1,050-file sync in Virtual Files mode, after several account reset/re-add and local folder delete+recopy cycles during unrelated troubleshooting.

### Expected behavior

No minimal repro found. Occurred twice during a ~5 GiB / ~1,050-file sync in Virtual Files mode, after several account reset/re-add and local folder delete+recopy cycles during unrelated troubleshooting.

### Which files are affected by this bug

FileProviderExt.appex — not tied to a specific synced file's content; the crash is in the extension process itself, reconstructing an FPItem from its own local item database

### Operating system

macOS

### Which version of the operating system you are running.

macOS 26.6 (25G72)

### Installation method

Official Installer for macOS 13 and later

### Nextcloud Server version

34.0.1

### Nextcloud Desktop Client version

34.0.0

### Did this occur after an update or on a clean installation?

Minor version update (i.e. 33.0.0 → 33.0.1)

### Are you using the Nextcloud Server Encryption module?

No

### Are you using an external user-backend?

- [x] Default internal user-backend
- [ ] LDAP or Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell

```

### Additional info

(Relevant Desktop client logs attached below)

## Environment

- Nextcloud Desktop Client: **34.0.0** (`CFBundleShortVersionString`), the
current stable release at the time (released 2026-07-28).
- macOS: **26.6** (build `25G72`).
- Sync mode: Virtual Files (File Provider / VFS), not classic full local
sync.
- Server: Nextcloud 34.0.1, self-hosted.
- Trigger: uploading a large synthetic corpus (~1,050 files, 5 GiB total,
mixed file sizes from 1 MiB to 512 MiB) into a Virtual Files-backed
account, immediately after several account resets/re-adds and local folder
delete+recopy cycles during troubleshooting of an unrelated upload issue.

## Observed severity pattern

- **First occurrence**: after the extension had been running for a while
under real upload load, followed by a full quit+relaunch of the app.
Result: the extension crash-looped continuously — a fresh process every
30-60 seconds, each one only logging its own startup line before dying —
for about 3 minutes, effectively blocking all sync activity (nothing could
progress far enough to enumerate files or start uploads).
- **Fix applied**: used the desktop client's own built-in **"Reset File
Provider Domain"** button (Settings → account → "If this account's files
appear stuck, missing, or out of sync in Finder, reset its File Provider
storage. Unsynced local changes are preserved."), followed by a full
quit+relaunch of the app. This resolved the rapid crash-loop — the
extension then ran stably for roughly 30 minutes under continued heavy
upload load.
- **Second occurrence**: a single recurrence of the *exact same* crash
signature about 27 minutes later, again mid-upload, but this time it was a
single isolated crash rather than a loop — the extension respawned and
continued working normally afterward.
- **Third occurrence**: the next day, after fully deleting the remote test
folder, removing the local copy, running **"Reset File Provider Domain"**
again (which discards the domain's local database entirely and creates a
brand-new domain identity), and re-copying a fresh, freshly-verified copy
of the same synthetic corpus. The same crash signature recurred within
~15 minutes of the fresh sync starting, alongside 1,136 logged errors in
that sync attempt (mostly "No metadata for enumerated item found" and
"Could not upload item with filename" entries).

The third occurrence is the most important data point: it happened on a
**genuinely fresh domain**, ruling out "accumulated corruption from repeated
resets/re-adds" as a necessary precondition. Whatever produces the
missing-identifier item can apparently arise during ordinary heavy sync
activity on a clean local database, not only after prior churn. The earlier
theory (reset clears a specific bad record) still explains why the reset
*reduces* crash frequency for a while, but something during large/heavy sync
activity itself appears to be able to (re)introduce the bad state.

## Separately relevant context (not the same bug, but co-occurring)

During the same session, Finder separately reported the account's File
Provider connection as **"signed out"** (distinct from the main app's own
account/login state, which showed normally connected/"All synced!"). Signing
back in via Finder's own "Sign In..." prompt resolved this instantly with no
re-authentication friction. This looked like the File Provider extension's
domain-level session becoming stale/desynced from the main app's session,
independent of the crash above, though it's plausible both symptoms share a
root cause in the same local File Provider state store.

## Impact

For a solo/small-scale user this is a serious reliability concern for the
Virtual Files feature specifically: repeated silent stalls during a large
sync, with no user-facing error beyond "nothing is happening," and the only
discovered mitigation is a manual, non-obvious admin action (Settings →
Reset File Provider Domain, or account remove/re-add) rather than automatic
recovery.

## What would help maintainers

- Whether `__FILEPROVIDER_BAD_ITEM_MISSING_IDENTIFIER__` from a third-party
extension's local item database is already a known, tracked failure mode
(closest related issue found:
[nextcloud/desktop#9776](https://github.com/nextcloud/desktop/issues/9776),
which describes a related "degraded File Provider database" / missing
metadata state on macOS, but not this exact assertion).
- Whether the Realm-backed local item store can end up with a record missing
a required identifier under any known condition (e.g. rapid account
reset/re-add cycles, or interrupted large syncs), and whether that could be
defended against with a schema/validation check before handing the item to
`FileProvider.framework`, rather than letting the framework's own assertion
abort the whole extension process.
- Full `.ips` crash reports for both occurrences are available if useful (not
attached here to keep this report to text).

[nextcloud-crash-log-slices.jsonl.txt](https://github.com/user-attachments/files/30629589/nextcloud-crash-log-slices.jsonl.txt)

Start by tracing FileProviderExt.appex item lookup and changes-observer update handling, then inspect the Realm-backed local item records involved in constructing FPItems. Use the supplied crash-log slices and a large Virtual Files sync to investigate missing identifiers. Done means the crash is reproducible or explained, malformed records are safely handled, and regression coverage verifies the extension does not abort.

Written by the indexing model from the issue text.