Bulk import not fixed

Following up on this: it is not fixed. I retested today on v1.70.2 — three minor versions on from the 1.67.19 report — and reproduced it identically with the same 10-row CSV.

But the more urgent problem is what the crash left behind. My space no longer loads its content in any client, desktop or web, while the REST API serves it perfectly. I cannot browse my own library.

1. The import commits correctly, then the worker dies While the desktop app was deadlocked, I queried the public REST API and found all 10 Book objects written correctly — titles intact, and the Author entity property populated with real links to People objects (Christopher D. Winnan, Robert Munsch, Rosemary Coates, …).

So this is not a data or validation fault. The import job completes and persists everything, including the two-way entity links. The worker dies after a successful commit — this looks like cleanup or post-commit link reconciliation.

1. The trigger is the entity-mapped column Since August, the two Book properties that were both displayed as “Author” have been renamed, so they are now distinct — Author (entity → People) and Author - Text (richText). The mapping step was therefore completely unambiguous this time. I mapped the CSV’s Author column to the entity → People property, and it still crashed.

That rules out mis-mapping and leaves the entity-mapped column as the common factor across all three reproductions.

1. Since the crash, content will not load in any client After force-quitting and restarting, the desktop app reports itself completely healthy: Dead Workers: none Portal: reachable; S3: reachable Sync: "All content synchronized to the server." [green] "All updates from other devices received." [green] Offline: "Content downloaded" [green] "Media downloaded" [green] But under Local Storage: Content: 2.05 KB (2 spaces) <-- a ~21,000-object space Media: 1.72 GB (3 spaces) Every view that requires full local content shows “View is not ready yet — this view requires all content to be loaded on your device.” It never becomes ready.

This is not confined to my desktop profile. I opened the same space in the web app at app.capacities.io, which is a separate client with its own local store, and it fails the same way. Notably, the sidebar there does show the object type and its count — Books 1185 — so structure and counts arrive, but the content behind them never does.

Two independent clients, same failure, on a space the API serves without issue. That suggests the problem is in content delivery to clients rather than in one corrupted local database.

It affects every object type, not just the one I imported into. Books fails, but so does Affirmations — an unrelated type that the CSV import never touched. So this is not corruption of the Book structure; the whole space fails to load content.

Repeated downloads add almost nothing. Across four separate full-download attempts, the reported content size has moved: 1.96 KB -> 2.03 KB -> 2.05 KB -> 2.08 KB Each run reports success and re-arms the “Content downloaded” flag. It looks like the client is receiving a near-empty payload, accepting it as the complete space, and marking itself done.

1. No client-side recovery works Attempt Result Recalculate content index Content unchanged at ~2 KB Reload app No change Sign out, sign back in Flags reset to “is being downloaded”, a transfer ran, then see below Open space in web app (separate client) Same “View is not ready yet” The sign-out/in is the informative one. A transfer genuinely ran — roughly 1,125 files written under ~/Library/Application Support/Capacities, about 35 MB. But comparing before and after shows what actually arrived: Media: 1.71 GB -> 1.72 GB (media downloaded) Content: 1.96 KB -> 2.05 KB (essentially nothing) It downloaded media and no content, then set Content downloaded back to green and returned to the same wedged state. So the client treats a content download that fetched ~0 objects as successfully complete, and re-arms the flag that prevents any retry.
2. The server side is fine throughout The public REST API has served this space normally the entire time. Right now it returns complete objects — properties, entity links, and block content: GET /object -> 200 structureId : e30bd202-21a7-4450-8563-fb9b5c3311bb property count : 21 blocks present : 1 So the data exists and is intact and reachable. It is only the clients that cannot get it.

One more mismatch, in case it is related: Diagnostics reports Storage: 1.72 GB, but ~/Library/Application Support/Capacities holds 14 GB, almost all under File System. Roughly 12 GB appears orphaned — the old content store looks abandoned rather than cleanly cleared.

Reproduction environment Capacities v1.70.2; Mac OS v10.15.7; Chrome v148.0.7778.280 (WebKit v537.36) Desktop (Electron); en (America/Los_Angeles, UTC-7) Space ID: d167a8ed-192a-4bc7-8524-6a3a3e01bb68 Date: 5 September 2026

Diagnostics after all recovery attempts (20:47 local): Memory: 72.01 MB / 4 GB; Storage: 1.72 GB / 282.36 GB Portal: reachable; S3: reachable; Dead Workers: none

Import that started it: 10-row CSV, fallback object type "Book" Mapping: CSV "Author" column -> Author (entity -> People) Result: import succeeds, data committed, app hangs at 0% CPU

Questions How do I get my library loading again? This is the pressing one — I currently cannot browse my own space in any client. Reindex, reload, and a full sign-out/in have all failed, and the web app fails too, so I do not think clearing the local profile will help. Is there something server-side that needs resetting for this space? Should the client be setting “Content downloaded” after a download that retrieved no objects? That flag is what blocks every retry. Is the ~12 GB of unaccounted data under File System safe to delete? Can you tell me how much of my 5,000-object API creation quota is still available? There is no API route that reports it, and with bulk import unusable I may have to fall back to creating ~3,600 objects over the REST API. I would rather not start that without knowing whether it can finish — a run that exhausts the quota partway leaves me with a half-imported library and a permanently spent allowance. Context This began as a ~3,600-object migration (a Kindle + Audible library sync). Your docs recommend bulk import over the API for exactly this kind of work: If you want to bulk import objects, we recommend to use the bulk import feature in the app instead. My workaround is to import with the entity column omitted entirely, then link authors afterwards via PATCH (which does not draw on the creation quota). I have not been able to test it, because the client has been unable to load content since the crash.

Happy to send the full diagnostics file with console logs if useful.

Thanks, Taj