Upload errors, decoded

Every error LumiDevKit can show you on upload, what actually causes it, and the fix. Find your message below.

Enlarge

Please upload a .json, .bubble, or .sql file

The file extension is not one LumiDevKit accepts.

The Database Visualizer takes .json, .bubble and .sql. The other tools take .json and .bubble.

Renaming works, but the extension is not cosmetic: it picks the parser. A .sql file goes to the SQL parser and everything else goes to the JSON one, and that choice is made before either of them looks inside the file. So renaming a Postgres dump to .json does not help, it just fails differently. Only text pasted into the box is judged by its content.

File is too large (max 50MB)

The hard limit is 50 MB.

Two things to try:

• Run the file through the JSON Sanitizer first. It deletes all of settings.secure and the credential-bearing keys under settings.client_safe, so it helps most when a plugin or API Connector block is what made the file heavy. Your pages, workflows and element definitions pass through untouched, so on a big app export the saving may not be enough on its own.
• For the Database Visualizer specifically, you do not need the whole app. Any file with a user_types key works, so a previously downloaded schema JSON is far smaller.

Every uploader says so when it refuses a file, so a drop zone that appears to do nothing at all is worth reporting rather than a size or extension problem on your end.

The JSON Sanitizer is the one tool with no size limit, and that is deliberate: this page sends you there as the fix for hitting the limit elsewhere, so capping it too would be circular.

No database types found

Full text: "No database types found. Upload a Bubble app/schema export (.json) or a Postgres schema (.sql)."

The file parsed fine, but it has no user_types key at the top level.

Causes, most common first:

• You uploaded something that is not a Bubble export at all.
• The JSON has user_types nested inside another object. Only the top level is checked.

If an AI wrapped its JSON in explanation you get a different message, not this one, because the file never parses at all. See Unexpected token … is not valid JSON.

See the schema format for exactly what the file must look like.

Invalid Bubble schema format. Expected user_types object

You will not see this from an upload. The importer checks for user_types before the store does, so a file without it produces "No database types found" above and stops there. What reaches this section in practice is the shorter "Invalid schema format.", shown when a saved schema no longer parses.

Note that "user_types": {} is accepted. An empty object is valid and gives you a diagram with just the built-in User on it. If that is what you are seeing, your file parsed correctly and genuinely contains no data types. An array is accepted for the same reason, since the only test is that the value is an object and an array is one.

Invalid Bubble JSON format. Expected workflow data

From the Workflow Tracer. The file has none of pages, element_definitions or api.

Almost always this means you uploaded a database-only schema file instead of a full application export. See which file does each tool need?.

No workflows found in the uploaded file

The file is a valid application export, but nothing in it defines a workflow. Check you exported the right app.

Invalid Bubble JSON format. Expected pages and/or element_definitions

From the Reusables Tree. Same cause as the workflow message: you need a full application export.

Invalid Bubble JSON format. Expected pages or element_definitions

From the Audit tool. Same cause again.

Invalid Bubble JSON format. Expected pages or element_definitions with styles

From the Design System tool. The message overstates the requirement: the check behind it is the same one the Audit and Reusables Tree run, and it only fails when the file has neither pages nor element_definitions. A file with no styles parses fine, it simply has no named styles to report.

If you sanitized the file with a tool other than ours, it may have stripped styles or settings. That will not trigger this error, but a missing styles block leaves the style names empty, and a missing settings block costs you the editor's own colour and font tokens and the app's custom breakpoint sizes. Bubble's eight built-in breakpoints still show either way. LumiDevKit's own JSON Sanitizer deliberately preserves the design-related keys.

No pages or reusables found in the uploaded file

From the Reusables Tree and the Design System. The file cleared the pages / element_definitions check, but neither key holds anything the tool can draw.

A real Bubble export cannot produce this. Every export carries its pages, and the JSON Sanitizer keeps them, so the file is hand-made, AI-generated or hand-edited with an empty or mistyped pages block.

The two tools disagree at the edges. The Reusables Tree skips a page entry whose type is set to anything other than Page, while the Design System does not filter on type at all, so the same file can come up empty in one and load fine in the other.

No findings for this action in the uploaded file

From the Audit tool. This is good news. The check ran and found nothing wrong. It is phrased as an error because it appears in the same slot; it does not mean anything failed.

Invalid JSON file. Please check the file and try again

From the JSON Sanitizer. The file is not valid JSON at all.

The usual cause is a truncated download or a partial copy-paste. Worth knowing: the Sanitizer is the one uploader that does no repair. The others quietly fix a missing opening brace, a single trailing comma and unbalanced closing braces before giving up, so a file that loads elsewhere in LumiDevKit can still fail here, and one missing brace is enough.

JSON must be an object with keys. This file has an unexpected format

From the JSON Sanitizer. The file is valid JSON but is an array or a bare value rather than an object.

JSON file appears to be truncated or malformed

The file ended mid-structure. Re-export it from Bubble and make sure the download completed.

Unexpected token … is not valid JSON

This one is not LumiDevKit's message, it comes from the browser's own JSON parser, so the exact wording varies: "Unexpected token 'H', "Here is yo"... is not valid JSON".

Read the snippet the message quotes, because it tells you which of two different problems you have.

The snippet starts at the beginning of the file. The content is not JSON from the very first character, and the usual cause is text wrapped around it: an AI's reply copied along with its explanation, or with the ```json fence still attached. Delete everything before the first { and everything after the last }. LumiDevKit repairs a few kinds of truncation, but it never strips a preamble.

The snippet opens with .... The file is fine up to that point and breaks further in, so trimming the ends will not help. The usual cause is a value JSON does not allow, left behind by whatever wrote the file: True, None or undefined where JSON needs true, null or a real value. Fix that value instead.

Could not parse SQL

Full text includes the underlying parser's message, usually with a line number: "missing ')' at ';' (near line 4)". A few arrive without one, because the parser crashed rather than reporting a diagnostic. A column written with no type at all is the common case.

Some of these messages are very long. A trailing comma in a table body makes the parser list every keyword it would have accepted at that point, which runs to thousands of characters. Only the useful part is shown; Show full message has the rest if you want it.

LumiDevKit parses Postgres only. CREATE TABLE and CREATE TYPE … AS ENUM define the diagram. Foreign keys are read whether they are written inline as REFERENCES table(column) or added later with ALTER TABLE … ADD CONSTRAINT … FOREIGN KEY, and both produce the same relationship. On top of those come ALTER TABLE … ADD CONSTRAINT … PRIMARY KEY, inline CHECK (col IN (…)), INSERT INTO … VALUES seed rows and LumiDevKit's own COMMENT ON markers. Everything else, indexes and policies included, is ignored rather than rejected.

That makes this error narrower than it sounds. It fires when a CREATE TABLE or a CREATE TYPE … AS ENUM statement cannot be read:

• The column syntax is not Postgres, but is close enough to reach the parser. AUTO_INCREMENT and AUTOINCREMENT are the usual ones.
• The table body is malformed and a closing ); still appears further down, which is what happens when a truncated paste runs into the next CREATE TABLE. A paste that simply stops mid-table gives no error at all: only complete CREATE TABLE … ); statements reach the parser, so the unfinished one is dropped and that table is quietly missing from the diagram.

A MySQL or SQL Server dump that quotes its identifiers with backticks or brackets never reaches the parser at all, so it gives you an empty diagram rather than this error. A data dump with no CREATE TABLE in it does the same.

See import a Postgres schema.

Please log in to see your saved schemas

Not what it sounds like. You cannot reach the saved-schema list while signed out, because you are sent to the login page before the page ever loads.

So this means the tab was already open when the session ended: you signed out in another tab, or the cookies were cleared. The open page has no way to know that until it asks the server. Reload and sign in again.

The file uploaded, but the diagram looks wrong

No error message, but the result is not what you expected. This is the most important section on the page, because the schema parser does not reject bad input — it renders it.

• Red [Missing: X] boxes — a field references a type that does not exist.
• A box labelled undefined — that data type has no display. Data types have no fallback, unlike option sets, which fall back to their key.
• A list field with no relationship line — the type string was not recognised, most often list.user where it should be list.custom.user.
• Fewer types than expected — two of them collided on the same key.
• A type you know exists is absent — it is marked deleted, and deleted items are hidden by default. Toggle Show deleted.

All of these are explained in the schema format.

A .sql file behaves the same way. With no CREATE TABLE statements in it, it loads as an empty schema and draws a diagram with only the built-in User on it, rather than reporting an error. See import a Postgres schema.