Lints

sendflow-lint runs two kinds of check. Structural lints need no knowledge of your account and always run. Registry checks need to know what attributes, events, topics, templates, lists and webhook endpoints exist, and are skipped if you do not supply a registry.

Errors fail the build. Warnings do not — they are things that are probably wrong, and occasionally exactly right.

Structural — errors

These are all caught with no registry at all.

The webhook label and the reply-to address are in that table rather than the registry one because they are format rules, not lookups: neither resolves against anything in your account, so the checks need no account context and run whether or not you pass -registry.

The split one is worth dwelling on, because it is the check that pays for itself:

workflow "t" v1 {
  enter on segment "trial-started"

  split {
    30%: { send "a" via topic "marketing" }
    30%: { send "b" via topic "marketing" }
  }
}

Forty percent of the contacts in that split go nowhere. In a canvas you would find out from the send volumes a week later. Here it does not compile.

Structural — warnings

A failed: arm counts as a level, exactly as a timeout: arm and an if block do.

Two calls at one address

The duplicate-call warning is worth a paragraph, because what it is protecting is not in your file at all — it is in the service on the other end.

A call identifies itself to the receiver by its endpoint key and its label, and by nothing else. Two calls sharing both are one address for two steps: the receiver gets two requests it cannot distinguish, and neither can whoever reads the delivery log afterwards. The remedy is a label, which is why the message names one.

workflow "Two identical calls" v1 {
  enter on segment "trial-started"

  call webhook "mobile-push"
  wait 1d
  call webhook "mobile-push"
}

warning: duplicate webhook call "mobile-push" with no label (first at 4:3) — label each call so the receiver can tell the steps apart

The check is flow-wide, not per-block: two calls in different if arms still collide, because the receiver sees a flat stream of requests and has no idea which branch produced one. Give each call its own label and the warning goes away — the same endpoint serving five steps is exactly what labels are for.

Registry checks

These need -registry. Without it they are silently skipped, which is why a clean sendflow-lint with no registry means considerably less than it looks.

Plus every diagnostic SendQL itself produces, for every embedded predicate — unknown attributes, type mismatches, reserved words, and the absence lint. They report at their real line and column in the .flow file. See SendQL’s type rules.

Checked when you save in SendOps

A few checks need more of your account than a registry file describes, so SendOps runs them when you save a workflow and sendflow-lint does not:

The absence warning, in a workflow

The one you will see most often, and the one most worth not ignoring:

if attr.plan != "trial" { ... }

warning: predicate on `attr.plan` excludes contacts where it is unknown — add `or attr.plan is unknown` to include them, or `has attr.plan` to silence this

In a branch, an excluded contact does not vanish — they take the else arm. That is how the wrong cohort ends up receiving the wrong email, and it is why this is worth a warning even though it is frequently harmless. See the absence contract.

Reading a diagnostic

flows/winback.flow:8:3: warning: unreachable: this statement follows an exit
                  │ │  │
                  │ │  └─ severity: error or warning
                  │ └──── column
                  └────── line

Errors and warnings both carry a precise position, because parsing and analysis both track one. The CLI prints a caret under the offending token.

Exit codes: 0 clean, 1 a parse failure or any error, 2 a usage or I/O problem. Warnings alone do not fail.