State and lifecycle
Understand which calculations are recreated and which instances retain state during a session.
State lifetime determines whether a calculation remembers prior observations. Choose that lifetime deliberately instead of relying on a name shared by two APIs.
On-demand calculators
cal(name, params) constructs a fresh registered calculator instance for each call. Its constructor fields do not become persistent strategy state across calls. The calculation can still read session context or external history.
This means “fresh instance” does not necessarily mean “uses only this bar.” For example, SMA queries historical data for its time window.
Configured models
The session loader constructs configured models and stores them in the relevant runtime collections. Those instances can accumulate state across their subsequent callbacks.
context.algos creates a lookup facade over the configured L2 tick collection. Calling find returns an existing instance; creating another facade does not reset that instance.
Some registered session models configured through the L1 model collection are mapped into L2 and shared between tick and position-processing collections. This allows their state to continue across changes in position status.
Script-owned state
Use context.sjsState for state your SJS strategy explicitly owns, such as the previous relationship between two averages. Treat it as runtime state, not a promise of durable persistence across restart or publication.
Keep example state under a dedicated key to avoid accidentally mixing unrelated script experiments. Start a fresh session when testing changed initialization or sampling assumptions.
Skip behavior
SJS skip and skipall affect later algorithm execution in the shared frame. Session models marked isSession are exempt from the ordinary L2 skip check, so calling skipall is not a universal freeze of every calculation.
The runner's position branch is selected from its earlier position snapshot. Do not assume that an SJS action reorganizes all later callbacks as if the frame started in the newly updated state.
Read execution flow for ordering, then execution primitives for action ownership.