What Save Would Refuse

Description

When you press Save on a step, PlaidCloud checks its settings and refuses any it can’t run, such as an expression that doesn’t compile or a column used in a way its type doesn’t allow. While you edit a step, Weave now runs most of those checks as you go and shows what Save would refuse in a strip just above the Save buttons:

1 problem that Save will refuse.

Each problem is listed under that line. When it names a row on the Table Data Selection tab, Go To opens that tab with the row selected.

The checks read only the step’s settings and your project’s variables, so they are quick, and no AI is involved. They never block the save: Save stays available, and it runs every check itself when you press it.

What the Strip Says

Weave says	What it means
Checking this step for problems…	Weave is running the checks on your latest change.
1 problem that Save will refuse.	Save would refuse the step as it stands. Each problem is listed below it.
No problems found. Save checks a few more things, such as the source and target tables.	The checks run while you edit found nothing. Save still runs its own checks, including some this strip skips.
Weave couldn’t check this step’s expressions. …	Part of the step couldn’t be checked; the reason follows. This is never a pass.
Weave couldn’t check this step just now. Save still checks it.	The check didn’t run, for example because the server was busy. Your next change asks again.

Why Expressions Couldn’t Be Checked

Reason	What it means
This step isn’t in a workflow, so its expressions can’t be checked. Save doesn’t check them either.	Expressions can use workflow variables, so they are checked in the step’s workflow. A step you opened outside any workflow isn’t checked, here or by Save.
Some of its expressions are in settings Weave can’t check yet.	The step keeps some expressions in settings these checks don’t read, such as a second source’s filter. The others are still checked.
Its column setup is one Weave can’t check yet.	The step lists its columns in a way the check can’t compile, as a Multi-Table Join does.

An expression that uses a variable neither the workflow nor the project defines is a problem, not a reason: “An expression uses the variable rate, which isn’t defined in this workflow or project.” So is a brace that starts or ends no variable name, as a half-typed variable has: “An expression has a brace that isn’t part of a variable name.” Save refuses both with the same sentences.

In the Expression Editor

Open the Expression Editor from an Expression cell on the Table Data Selection tab, or from Select Subset of Data or Apply Secondary Filter to Result Data on the Data Filters tab, and a line under the editor checks the expression as you type:

The editor says	What it means
Checking…	Weave is checking what you just typed.
No errors found.	The expression compiles the way Save compiles it. Point at the line to read what this leaves out: Weave checks the syntax and the column names; some errors only show when the step runs.
Error: …	Save would refuse the expression, for the reason given. A syntax error is also marked on its line, beside the line number.
Couldn’t check. …	The expression couldn’t be checked, for one of the reasons above.
Couldn’t check just now. Saving the step still checks it.	The check didn’t run. Pressing Save on the step still checks the expression.

The editor checks against the step’s settings as they were when Weave last checked the step, with your expression in place. Opened from anywhere else, such as the Table Explorer, it shows no line.

When It Appears

While you edit a step you can change. A step that opens read-only for your role isn’t checked as you edit.
After each change, once you pause. A change that leaves the settings as they were isn’t checked again.
It reads the step’s settings and the project’s variables, so it never costs an AI call and never queries your warehouse.