When your code runs, and with what index

A Lipi script is handled in two modes: it is checked, and it is run. Both are modes of the same interpreter, and they are separate.

Checking

The editor checks a script without running it. A script that passes has been parsed, scoped and type-checked. It has not been evaluated on a single bar.

Each problem found is reported with a start and an end position, so it points at the text that caused it.

Passing the check is therefore a statement about the shape of your code, not about its behaviour on data.

Running

When the script runs, it is evaluated once per bar, in order.

The interpreter is initialised for each evaluation rather than shared between scripts. One script cannot read another’s state.

indicator("Close")

plot(close)

That is the smallest complete script: one declaration and one output.

Which failures belong to which mode

Some failures cannot appear until the script runs, because the checks that catch them are in the running interpreter rather than in the checker.

The lookback limit is the clearest example. Asking for a bar further back than the limit allows fails while the script runs, not when it is checked, so a clean check does not rule it out.

Resource limits in general are enforced by the interpreter. Exceeding one produces a diagnostic rather than a quietly truncated result.

What this page does not tell you

The realtime call contract is not documented here.

It does not tell you whether an initial call, a full recalculation and an update call are distinct events, what index a run starts from, whether that index can go backwards, how many bars can arrive in one update, or what triggers a run. None of that is settled here, and none of it should be inferred from the two modes described above.

For the flags that report where a run sits, see Bar-by-bar evaluation and Recalculation and confirmation.