Screener execution and caching

Also seen as: running a screen, executing a screener

What are the states a screener run passes through?

A match run is short and has three visible outcomes: while it is in flight the results area reads Refreshing matches…; on success the matches replace it; on failure it reads Couldn't run the screen. with the reason. A run that finds nothing is not a failure — it shows No instruments match your filters, which points at filters that are too tight or that contradict each other.

A screener backtest is a longer job and reports more. Before it has ever run, the band carries no status at all and the panel shows the never-run preview instead. While it runs the action reads Backtesting {percent}% and the panel shows Computing performance across six horizons with that percentage — that running display covers the whole wait, from the moment you start the backtest until the results appear. On failure the status reads Failed and the action becomes Retry backtest; while market data is being loaded the band reads Refreshing data… instead of computing. Editing a filter afterwards does not invalidate the result on screen: the banner reads Out of date — filters changed since the last backtest. Showing the previous run. until you re-run it.

Why do I get the same matches every time — and why is a re-run backtest instant?

For two different reasons. Matches are computed on every run: you get the same list because the same filters over the same day's data produce the same result, and it changes the moment either side changes. A screener backtest you have already run comes back without computing again, which is why opening it a second time that afternoon returns at once.

Both are ended by the same event. When the daily market-data refresh advances the frontier, a match run starts producing different numbers and the first backtest of the new day computes in full again — so its figures can differ slightly from yesterday's even though you changed nothing. No result ever straddles a refresh.

Defaults in Fincanva

• A screener always runs against the most recent loaded market close; there is no option to run it as of another date.
• A match is an instrument, not a ticker string: it is listed under its current ticker and name, but its identity is its permanent instrument identifier, so a company that changes ticker does not become a different match.
• While market data is loading, a screener reports the refreshing state instead of computing — it never returns a partial or stale answer as if it were current.
• A screener backtest re-runs the screener on every monthly screening date from 2000 to the frontier, which is why it takes long enough to report progress while a match run does not.
• A result belongs to the screener that produced it, not to the account that asked for it — the same principle as shared compute for strategies.

Worked example

You open a screener with four filters and run it: the results area shows Refreshing matches… for a moment, then lists 47 matches. You loosen one filter and run again — a different screener now, so a different answer: 88 matches. You put the filter back and run once more: 47 again, recomputed from scratch but identical, because the filters and the day's data are the same as the first time.

Now the backtest. You press Run backtest, watch it pass through Backtesting 62%, and the horizon returns appear when it finishes. You leave the page, come back twenty minutes later and press Run backtest again — the view did not keep the earlier result, but the answer returns at once instead of computing, served from the result already held. The next morning, after the overnight refresh has advanced the frontier by one trading day, the same backtest computes from the start, and its horizon returns shift slightly with the extra day of data.