Guide

Dynamic Requests in Pine Script v6: Multi-Symbol Scanners

The one v6 feature that unlocks a whole category of tools. Here is how to request data for a list of symbols inside a loop, and how to stay under the memory limit that causes the RE10139 error.

•11 min read

In Pine Script v5, the symbol you passed to request.security had to be effectively fixed at compile time. You could request one other symbol, or a handful of hardcoded ones, but you could not loop over a watchlist and request each ticker in turn. That single restriction is why real multi-symbol scanners were impossible in v5.

Pine Script v6, which launched in November 2024, removed it. The request functions now accept series arguments for the symbol and timeframe, which means the ticker can come from a variable that changes inside a loop. This article is about what that unlocks and the limit you have to respect to use it.

What "dynamic" actually means here

Dynamic simply means the argument can vary at runtime rather than being fixed in the source. Because the symbol can now be a series string, you can hold a list of tickers in an array, loop over them, and call request.security with each one. The result is that a single indicator can pull the latest close, RSI, or trend state for a dozen symbols and rank or filter them, all on one chart pane.

pine
//@version=6
indicator("Simple watchlist scanner")

symbols = array.from("AAPL", "MSFT", "GOOG", "AMZN", "NVDA")

f_rsi(sym) =>
    request.security(sym, timeframe.period, ta.rsi(close, 14))

var table t = table.new(position.top_right, 2, 6)
if barstate.islast
    table.cell(t, 0, 0, "Symbol")
    table.cell(t, 1, 0, "RSI(14)")
    for i = 0 to array.size(symbols) - 1
        sym = array.get(symbols, i)
        r = f_rsi(sym)
        table.cell(t, 0, i + 1, sym)
        table.cell(t, 1, i + 1, str.tostring(r, "#.0"))

Notice the request is wrapped in a function and the table is only filled on the last bar. You do not need the scan recomputed on every historical bar, and building the output once on barstate.islast keeps things fast. For why per-bar work multiplies, see why your Pine Script is slow.

Common scanner shapes

Three patterns cover most use cases. A watchlist dashboard requests one metric per symbol and displays them in a table, as above. A breadth indicator requests the same condition across many symbols and counts how many meet it, for example how many members of an index are above their 200-day average. A sector-rotation view requests performance over a window for a set of sector proxies and ranks them. All three are the same core loop, differing only in what they compute and how they present it.

pine
//@version=6
indicator("Breadth: how many above 200 SMA")

symbols = array.from("AAPL", "MSFT", "GOOG", "AMZN", "NVDA", "META")

f_above200(sym) =>
    request.security(sym, "D", close > ta.sma(close, 200) ? 1 : 0)

var int count = 0
if barstate.islast
    count := 0
    for i = 0 to array.size(symbols) - 1
        count += f_above200(array.get(symbols, i))

plot(count, "count above 200 SMA", style = plot.style_columns)
PineScripter has the v6 manual as context, so it uses the current request syntax

The memory limit and the RE10139 error

Every symbol you request pulls its own data series into memory, and each series carries a historical buffer. Request too many symbols, or too much history per symbol, and you exhaust the memory budget TradingView allows a script. That is what surfaces as the RE10139 runtime error, whose message points at memory pressure from things like excessive requests, unnecessary drawing updates, or an oversized historical buffer.

The practical rules: keep the symbol count modest, request only the values you actually use rather than whole series you discard, avoid requesting more history than you need, and do the heavy assembly on the last bar instead of every bar. If you hit RE10139, reducing the number of requested symbols is almost always the fastest fix. The limit is real, so treat a scanner as a focused tool for a curated list, not a way to scan the entire market at once.

A note on repainting in scanners

Requesting data from another symbol or timeframe carries the same repainting risks as any request.security call. If you pull a higher timeframe without care, the value can change as the higher-timeframe bar forms. Use the confirmed-bar approach when the scan feeds a signal you act on, exactly as described in multi-timeframe analysis without repainting and repainting explained.

Getting scanners right without the trial and error

Dynamic requests are powerful but easy to get subtly wrong: too many symbols and you hit RE10139, careless timeframe handling and the scan repaints, work in the wrong place and it runs slow. These are exactly the details a generic AI, trained mostly on pre-v6 code, tends to miss, and it cannot see the runtime error to correct itself.

PineScripter works from the current v6 manual and validates against TradingView, so it uses the dynamic request syntax correctly and structures the loop to stay within the limits. If you want a watchlist scanner or breadth dashboard without grinding through memory errors, describe it at PineScripter and iterate from working code. To understand why generic models lag the language, see why ChatGPT fails at Pine Script.

Disclaimer: PineScripter is a coding tool for Pine Script development. It does not provide financial advice and does not guarantee trading profits. Always backtest strategies thoroughly and understand the risks before live trading.

← Back to Blog