[Bug]: Large legacy Site Export import fails with LiteDB "Detected loop in FindAll({0})"

[matt468779]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Importing a large legacy Site Export package (produced by DNN 9.10.2-era Site Export/Import, which uses LiteDB 3.1.0) fails validation with:

{"Message": "Package is not valid. Technical Details:Detected loop in FindAll({0})"}

VerifyImportPackage returns HTTP 400 and the import never starts. I expected the legacy export database to be upgraded/read successfully (or, if genuinely incompatible, to return a specific diagnostic rather than the low-level LiteDB message).

Steps to reproduce?

1. Using DNN Platform 9.10.2 (or any product built on it), create a Full Site Export whose ExportFolder collection contains more than ~2,550 records (e.g. create 3,000+ folders in the source site's file system before exporting).
2. Copy the resulting export package folder (containing export.json and export_db.zip) into App_Data/ExportImport/<packageName>/ on a fresh DNN Platform 10.3.x instance.
3. Go to Settings > Import/Export > Import.
4. Select the package and click Continue (this triggers VerifyImportPackage).

Current Behavior

After ~10 seconds, the request returns HTTP 400 with Package is not valid. Technical Details:Detected loop in FindAll({0}). The import wizard shows a generic error and does not proceed. Packages with fewer than ~2,550 records in their largest collection import successfully.

Expected Behavior

The legacy export database should be upgraded and read successfully by VerifyImportPackage, allowing the import to proceed — regardless of collection size.

Relevant log output

System.Exception: Detected loop in FindAll({0})
   at LiteDB.Engine.IndexService.FindAll(...)
   at LiteDB.Engine.RebuildService.Rebuild(...)
   ...

(Thrown from inside the LiteDatabase constructor when ConnectionString.Upgrade = true triggers an in-place rebuild of a legacy-format file.)

Anything else?

Root cause: ExportImportRepository (DNN Platform/Modules/DnnExportImportLibrary/Repository/ExportImportRepository.cs) opens every export database with:

this.liteDb = new LiteDatabase(new ConnectionString(dbFileName) { Upgrade = true });

A DNN 9.10.2-era export database is written in the legacy LiteDB v3.x on-disk format (internally "v7"). Opening it with Upgrade = true forces LiteDB to run a full in-place Rebuild(). LiteDB 5.0.21 — the version pinned in Directory.Packages.props — has a bug in that rebuild path: IndexService.FindAll uses a MAX_ITEMS_COUNT loop-detection guard that is initialized as if the target collection were empty, so any single collection above roughly 2,550 records falsely throws Detected loop in FindAll({0}).

This is a known upstream LiteDB defect:

• litedb-org/LiteDB#2525 — same exception thrown from Rebuild() on 5.0.21
• litedb-org/LiteDB#2582 — independent report of the same failure
• litedb-org/LiteDB#2603 (unmerged) — proposes computing maxItemsCount from source data instead of assuming an empty database

Since LiteDB is a binary dependency and there's no fixed stable release available, bumping the version isn't currently an option. I have a fix ready (detects the legacy file format by its header and migrates it into a fresh LiteDB 5.x database via normal inserts — which don't hit the broken rebuild guard — instead of the in-place upgrade, with the original fast path preserved for native 5.x and small legacy files) and will follow up with a pull request referencing this issue.

[matt468779]

I'll be submitting a pull request for this shortly — the fix is implemented and tested (unit tests with genuine LiteDB v3.1.0 fixtures included).