PIES Studio 1.9 · Documentation
What the messages in the PROBLEMS panel mean, and which ones you can do something about.
PIES Studio sorts build problems into two kinds, and the difference decides what you should do.
| Kind | What it means | What to do |
|---|---|---|
| Application | Something in your application is incomplete or contradictory — a step with nothing configured, a widget bound to nothing. | Fix it in the editor, or ask PIES AI to. The messages below are all of this kind. |
| Platform | The generated code itself is wrong. Your application is fine; our code generator is not. | Not fixable in the editor. Report it — nothing you change in your application will clear it. |
Application problems name one of your things: a screen, an event, a function, a table. Platform problems read like compiler output about generated code you never wrote. If a problem quotes source that is not yours and repeats after the automatic repair cycle gives up, it is ours — send it to us rather than working around it.
"has an orphan step … with no incoming link" A step is sitting in the flow with nothing leading to it, so it can never run. Open the event or function and link it from the step that should come before.
"has a dead-end step … with no outgoing link" The mirror of the same problem: a step nothing follows. Every step except the end must lead somewhere.
"must have exactly one start step" / "must have at least one end step" The flow does not begin or does not finish. Add the missing step.
"link references unknown from-step / to-step" A link points at a step that is no longer there — usually after deleting a step without repairing the flow around it. Delete the dangling link and reconnect.
"has duplicate step id" Two steps share an identity. This one is not repairable by hand; rebuild the event, or ask PIES AI to.
"step … has no configuration" The step exists but nothing was filled in. The message names what it needs.
"the If step … has NO condition" An If with nothing to test cannot compile. Give it a condition or remove it.
"blocks are never closed" Something opened — an If, a loop — and never ended. The message says how many more end steps are needed.
"Incorrect Configuration" on a Find Single Record step The value the step looks the record up by cannot be read — for example a field name with a space such as $Client ID, or free text. The message names the step and quotes the value. Pick the lookup value again from the list, or type it as $ followed by the field or variable name. Wrapped forms such as ${id} or {{id}} are read as $id for you.
"Find Single Record Has No Match Column Or Value" A Find Single Record step reads one record by matching a column to a value, and this one has no column, no value, or neither. The message names the step and what is missing. Pick the column and the value to match on. If the step was meant to group or count records (for a chart, say), Find Single Record cannot do that: use Find All Records, or the chart's own group-by. The rest of the app still builds while this step is fixed.
"Table Missing Data Source" A table exists in the data model with no source behind it. Bind it, or delete it if it was created by mistake.
"step … has no dataSource" A record step that does not say which table to read or write. The message lists the tables it can be bound to.
"Set Record Value step … assigns no column values" The step saves nothing. Either give it columns to set, or remove it.
"Set Record Value step … is missing variableName and/or type" The step does not say what it is building. Reopen it and complete the first constraint.
Every request to an application hangs after a code block ran A code block that opens a database transaction must end it with Commit or Rollback on every path, including when it returns early or fails. A transaction left open holds a database connection, and once the pool runs out every later request waits. Generated applications now roll such a transaction back automatically after 5 minutes (set PIES_TX_TIMEOUT on the backend, for example 2m, to change this), which frees the connection, but the work in it is lost. For long jobs, commit in small batches rather than holding one transaction open.
"Custom code blocks declare … more than once" Two code blocks define a function or variable with the same name. Rename it in one of them, or keep shared helpers in a single block. One code block can hold several functions and be called from as many steps as you like; it is built once, so its helpers are never declared twice.
"step … is missing the target screen" A navigation step with no destination. Choose the screen it should open.
"has an invalid navigation step" Navigation was given something that is not a screen. Pick a real one.
"the Custom Widget step … has no code block" A custom widget with no code in it. Add the code block, or delete the widget.
"NOT SAVED" — a save that would remove every widget from a screen PIES AI tried to save a screen with no widgets while the screen still had some. Nothing was changed, and the AI is told how to fix the save. If you do want the screen emptied, say so ("clear the screen") and ask again.
Not an error message — the most common report that is not one. In order of likelihood:
PIES Studio retries automatically, feeding each failure back for repair. If it stops before the build is clean it tells you why:
That distinction is the point of the message. It exists so you do not spend an afternoon rewriting a screen that was never the problem.
The PROBLEMS list comes from the last Build. Saving a change does not refresh it, so PIES AI cannot tell whether its edits cleared anything. When you ask it to fix problems and it changes something, its reply starts with Problems not re-checked yet. Run Build to see the new list; the count may stay the same or go up.
When PIES AI builds a whole application with a single agent and that agent saves tables but no screens, PIES AI runs one more pass that adds list, add and edit screens for the new tables. If that pass still adds no screens, the build ends with Build finished — added N table(s) but no screens instead of Build complete. The tables are kept; ask PIES AI for the screens you need (for example add list and edit screens for Contacts).
If the PIES AI service restarts while a build is running, the chat shows pies-ai restarted while this build was running. Click Continue to resume. The turn is kept as interrupted, not finished, and nothing is lost. Click Continue to pick the build up where it stopped.
Every AI model can read only so much at once. If what you send to PIES AI is longer than the chosen model can take, PIES AI refuses it straight away, without sending it to the model, and the chat shows Your message is too long for the model (about N tokens, the limit is L). Shorten it, split it into smaller requests, or attach it as a document. The limit depends on the model: for example about 400,000 tokens for GPT-5 models, about 200,000 for o-series models and about 128,000 for GPT-4o. A token is roughly four characters of English text. This is yours: shorten the message, split it, or attach the material as a document instead of pasting it.
If the AI provider rejects its key, or the key is missing, the chat shows one line: No working AI model is connected: the AI service key is invalid or missing. Open AI Settings ..., with a card that takes you to the setup. This is yours: open AI Settings > Providers and paste a valid key for the provider, or pick a model from a provider that is connected. PIES AI only falls back to models whose provider has a key, and removing a provider's key clears a model you had chosen from that provider.
If a build ends without starting the preview, or the preview stops (for example after the server ran short of memory), opening the preview address starts it again. You see a page saying the preview is starting; it checks by itself and opens the app once it is ready, usually within a few seconds. You do not need to build again.
If the page keeps waiting for more than a minute, build the app again from the editor. If the preview opens but its data does not load, build again too, and report it if it repeats.
A failed deployment says why. The deploy console in the editor shows Deployment failed followed by the reason PIES Studio recorded — for example connection to the build engine was lost mid-deploy — and, where there is one, a hint on what to do next. The same reason is shown on the deployment's page.
While a deployment runs, the editor's preview is shut down, so the browser console may list Failed to load resource: net::ERR_CONNECTION_REFUSED errors. They are expected and are not the cause of a failure; read the reason in the deploy console instead. A reason about the build engine or the connection is ours: deploy again, and report it if it repeats.
When the app's web build itself fails, the reason ends with the last part of the build output, so you can see which package or script the build could not find. Publishing an app that has not been built for several hours can take a little longer: PIES Studio reinstalls the app's packages before it builds.
A deployment runs the app as it was when you last published it. A function you added in the editor afterwards shows in the app and in the preview, but the deployed app does not have it yet: an agent that calls it is told the function is not in this deployment, with the time it was last published. Publish your changes with Update on the deployment, then try again.