EngineSQL-Inspired Rules / SQX

Debugging SQX

Trace a rule from its physical line through calculations, targets, and execution.

Start with the saved source and the first unexpected bar. Inspect parsing, model values, branch selection, target updates, and order outcomes in that order.

A line is invalid

Keep the complete rule on one line. Use uppercase keywords, spaces around comparisons, space-separated IF parameters, and comma-separated WITH/SET parameters. Remove unsupported parentheses, expressions, dotted access, and inline comments.

An editor may retain the last valid compiled configuration while reporting a source error. Correct the error and verify the saved revision before drawing conclusions from a run.

The rule parses but behaves incorrectly

Check OR first: the current text parser produces AND for multi-condition groups, even when OR was written. Use SJS for OR and nested conditions.

Check exact registry names, property names, units, and value types. Parsing does not validate runtime capabilities. A misspelled calculation can fail during evaluation; a misspelled target property can produce no useful update.

No target changes

Confirm that the target primitive was declared and belongs to the branch being evaluated. TICK is the flat-position branch; POS is the matching-position branch. The branch snapshot is taken before SJS runs.

Read each calculation's value and match diagnostics. Missing history, timezone differences, neutral values, and earlier skip controls can change the result. Later matching rules can overwrite earlier target updates.

A target changes but no order appears

SET changes an existing primitive's property. Confirm that its callback ran, action and size are correct, and transmission is enabled only when intended. Then inspect automation/L3 controls, eligibility, pending orders, and the adapter response.

Use size and limitPrice for the order primitive, rather than copying SJS request fields or outdated example aliases. The orders guide explains the next execution checks.

The same decision repeats

Threshold conditions run on every eligible frame. They do not track crossing transitions, cooldowns, or consumed events. Use SJS state for those requirements and explicitly coordinate any remaining configured primitives.

For a minimal report, retain the complete source line, declaration, saved revision, branch, bar timestamp, calculated values, target settings, and resulting request or absence of one.

On this page