Local database operations fail when origin is not whitelisted

[homostellaris]

Problem

I am trying to use Vercel preview environments but all database operations fail because the origin is not whitelisted. I get the following error when trying to add a record.

{
    "name": "DataError",
    "message": "Failed to execute 'add' on 'IDBObjectStore': Evaluating the object store's key path did not yield a value.\n DataError: Failed to execute 'add' on 'IDBObjectStore': Evaluating the object store's key path did not yield a value.",
    "inner": {}
}

What I've tried

I'm not able to safely whitelist the origin because its dynamic and multi-tenant.

https://starfocus-git-claude-database-mar-24e642-homostellaris-projects.vercel.app

I tried using a wildcard in the value for the origin but that didn't work.

I tried disabling the cloud addon conditionally in preview environments so I could at least test without the syncing feature but that resulted in the same error.

What I'd expect

I expected the DB would work seamlessly in the browser even if the cloud addon wasn't able to establish a connection with the backend.

[dfahlander]

Sorry for late answer. Looking in to it!

[liz709]

Hi @homostellaris!

I've been investigating this issue and found the root cause.

The Problem

When you say you "tried disabling the cloud addon conditionally", that's likely the cause of the confusing error. The @id syntax is specifically handled by dexie-cloud-addon - without the addon active, Dexie treats @id as a literal property name, which isn't a valid IndexedDB key path.

How @id Works

The dexie-cloud-addon overrides Dexie's schema parsing:

1. When it sees @id, it strips the @ and sets generatedGlobalId: true
2. A middleware then auto-generates unique IDs when you add records

Without the addon, @id is passed directly to IndexedDB, which fails because @ is not valid in a key path.

Workarounds

Option 1: Keep the addon but use a fallback database URL

Instead of disabling the addon, you could configure it with a non-syncing mode or let it fail gracefully:

db.cloud.configure({
  databaseUrl: process.env.DEXIE_CLOUD_URL || undefined, // undefined = no sync
  // ... other options
});

Option 2: Use standard Dexie schema in preview environments

If you really need to disable the addon, change your schema syntax:

// With cloud addon:
items: '@id, name'

// Without cloud addon (you provide the ID):
items: 'id, name'

And generate IDs yourself when adding:

await db.items.add({ id: crypto.randomUUID(), name: 'My Item' });

Regarding the Original Error

The error message Failed to execute 'add' on 'IDBObjectStore': Evaluating the object store's key path did not yield a value comes from IndexedDB, not Dexie Cloud. It happens because:

1. Without the addon, @id becomes a literal field name
2. Your objects don't have a field called @id (they just have name)
3. IndexedDB can't find the primary key value

---

That said, we should consider adding better error handling for this case - maybe detect @ in schemas when the cloud addon isn't present and throw a clearer error message.

Does this explanation help? Let me know if you need more guidance on setting up preview environments with Dexie Cloud! 🙂

[homostellaris]

Thanks @liz709 for the detailed explanation and @dfahlander for the quick response 🙏

Just so you know I ended up with a satisfactory solution for this by hooking into Vercel's repository dispatch events and whitelisting each new preview environment with the Dexie Cloud CLI in a GitHub runner, you can see what that looks like here.

That being said I would find it more intuitive if Dexie failed gracefully and continued to function as a local-only database when the origin was not whitelisted (perhaps with an error in the console).

[liz709]

Glad you found a workaround with the GitHub Actions + Dexie Cloud CLI approach!

One thing worth noting for tracking purposes: the underlying issue (a confusing DataError when the origin isn't whitelisted, instead of a clear "origin not allowed" message) is still worth fixing. Currently the error message gives no hint that the problem is the missing origin whitelist, which makes it hard to diagnose.

I'll leave this open as a polish/DX issue: Dexie Cloud should surface a clear, user-friendly error when an operation is attempted from a non-whitelisted origin, rather than a generic DataError.