run does not enforce the schema that config validate enforces

[turbolytics]

sqlflow run does not apply the JSON schema that sqlflow config validate applies. A config the validator rejects still runs, and the missing key changes behavior silently.

What happens

The schema marks batch_size required under pipeline. config validate enforces that:

$ sqlflow config validate pipeline.yml
Error: pipeline.yml is invalid: jsonschema validation failed with 'https://turbolytics.io/schemas/config.json#'
- at '/pipeline': missing property 'batch_size'

run accepts the same file and starts the pipeline. conf.Pipeline.BatchSize is then 0, and turbine.go:502 compares against it:

if numBatchMessages == t.batchSize {

numBatchMessages is at least 1 when that runs, so the comparison never holds. The count-based flush is unreachable. Batches close only on flush_interval_seconds, which defaults to 30 seconds.

Measured

Same three messages on the same topic, one config with batch_size: 3 and one with the key removed. Time from start to the first row reaching the sink:

Config	First output
batch_size: 3	0s
batch_size omitted	31s

Nothing in the logs mentions the missing key.

Why it matters

The failure is silent and it inverts the operator's intent. Someone who sets batch_size: 50000 for throughput, then loses the line to a bad merge or a templating mistake, gets a pipeline that still starts, still reports healthy, and flushes on a timer. Throughput drops and the cause is invisible. A validator exists that would have caught it, and run does not call it.

flush_interval_seconds has the same exposure. It is optional in the schema, so an absent value is legitimately 0, and root.go:324 defaults it to 30 seconds. That path is correct. batch_size has no such defaulting, because the schema says it is required.

Options

1. Validate against the schema in run, and exit non-zero on a violation. This makes the two commands agree, and it is the behavior the required list already promises. It rejects configs that run today.
2. Default batch_size in run the way flush_interval_seconds is defaulted, and drop it from the schema's required list. This keeps existing configs working. It needs a defensible default, and 1 is the slowest possible setting.
3. Validate in run and warn rather than exit. This surfaces the problem without breaking anyone, at the cost of two commands that still disagree.

Option 1 is the smaller change and the one that matches what the schema already declares. Option 2 is friendlier to configs in the wild. Either way run and validate should stop disagreeing about what a valid config is.

Found while reviewing the configuration docs, which claimed batch_size was optional and defaulted to 1. Neither half was true. Verified on v1.0.6.

Related: #142 and #169 cover validating the SQL itself. This issue is narrower: run should apply the schema validate already applies.