You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
request.security: helper parameter history and var color helper state are rejected #229
Two patterns that TradingView accepts inside request.security are refused by the transpiler. Both patterns are common in published scripts.
Versions
pineforge-codegen 1.6.1
Reproduction
History of a helper parameter fed from an indicator:
//@version=6
strategy('Helper history')
f(x) => x[2] - x
a = ta.sma(close, 3)
b = f(a)
c = request.security(syminfo.tickerid, '60', b)
plot(c)
CODEGEN 3:10 request.security helper-parameter history currently requires a direct OHLC/time bar-series binding
var color state inside a helper evaluated by request.security:
//@version=6
strategy('Color state')
f(x) =>
var color c = color.red
c := x > 0 ? color.green : color.red
c
c = request.security(syminfo.tickerid, '60', f(close - open))
plot(close, color=c)
CODEGEN 4:5 request.security helper-local var state currently supports only int, float, bool and string values
Expected
Both translate, with the helper evaluated in the requested timeframe's context as on TradingView.
Both still reproduce on main (aebad8c). Pointers in case they help:
var color in a helper. Numeric helper var state lives in a double series (see the _security_helper_var_state_type docstring), and the accepted set at codegen/security.py#L3072 leaves out int64_t. A color is a 32-bit 0xAARRGGBB value, which a double holds exactly. Admitting color-typed var state there, and casting back to int64_t on read, looks sufficient; the epoch-width int64_t case can stay refused.
Helper parameter history._compose_security_helper_history_subscript (codegen/security.py#L1680-L1723) only accepts parameters bound directly to OHLC/time, because requested-context history exists only for bar fields. Supporting src[n] for a derived argument means keeping that argument as its own series per call site, in the requested context. Pine gives each call site a history that advances only on bars where the call runs (the reason for TradingView's "should be called on each calculation" warning), so a call inside a conditional branch needs that same rule.
Thank you for the report. Confirmed in the v1.7.0 source: both patterns are still rejected (helper-parameter history over a series that is not a plain OHLC or time series, and var color state inside a helper evaluated by request.security). This is not fixed in v1.7.0. The two parts have different size: the var color helper state is the smaller one and we plan it first; the helper-parameter history needs a design for evaluating the helper in the requested timeframe's context. We plan to open a pull request for the var color helper state on 2026-10-29. For the helper-parameter history we expect to settle the design by 2026-10-28 and to open a pull request on 2026-11-03.
History of a helper parameter fed from a derived value (the first reproduction): codegen: request.security helpers may read the history of a parameter bound to a derived expression #262. f(x) => x[2] - x called as f(a) with a = ta.sma(close, 3) now translates; the helper reads the argument's own values on the requested context's bars, one history per call site. Shapes that cannot be sampled (a history offset that is not a non-negative constant, a conditional call, a helper that depends on other helpers' state, a mutable global that cannot be replayed, a parameter type without a lossless history) are refused with located errors, PF-E3094 through PF-E3101.
Both ship in codegen 1.8.0. Closing this issue as fixed on main; I will confirm here when 1.8.0 is published.
Thank you for both fixes. We re-ran our reproductions on main (11b5ca5, with engine 1.6.1): both cases from this issue now translate and run, and the cases from #226, #227, #228, #230 and #231 now behave as expected.
One shape of the first part still fails, with the same PF-E3011 as before. A value derived through a helper that reads its parameter's history translates when the request.security expression is the variable itself or a plain operator on it (b, b * 2, b > 0), but not when the variable is passed to a function, user-defined or built-in, or used in a ternary:
//@version=6
strategy('Helper history')
f(x) => x[2] - x
g(v) => v * 2
a = ta.sma(close, 3)
b = f(a)
c = request.security(syminfo.tickerid, '60', g(b))
plot(c)
CODEGEN 3:10 PF-E3011 request.security helper-parameter history currently requires a direct OHLC/time bar-series binding
The same error appears with math.sign(b) or b > 0 ? 1.0 : 0.0 as the expression. Since it is the old PF-E3011 rather than one of the new located refusals (PF-E3094 to PF-E3101), it looks like a shape the change did not reach rather than an intended limit. Could you reopen this issue or track it separately?
Activity
letiep97 commentedon Oct 20, 2026
Both still reproduce on main (
aebad8c). Pointers in case they help:var colorin a helper. Numeric helpervarstate lives in a double series (see the_security_helper_var_state_typedocstring), and the accepted set at codegen/security.py#L3072 leaves outint64_t. A color is a 32-bit0xAARRGGBBvalue, which a double holds exactly. Admitting color-typedvarstate there, and casting back toint64_ton read, looks sufficient; the epoch-widthint64_tcase can stay refused._compose_security_helper_history_subscript(codegen/security.py#L1680-L1723) only accepts parameters bound directly to OHLC/time, because requested-context history exists only for bar fields. Supportingsrc[n]for a derived argument means keeping that argument as its own series per call site, in the requested context. Pine gives each call site a history that advances only on bars where the call runs (the reason for TradingView's "should be called on each calculation" warning), so a call inside a conditional branch needs that same rule.luisleo526 commentedon Oct 25, 2026
Thank you for the report. Confirmed in the v1.7.0 source: both patterns are still rejected (helper-parameter history over a series that is not a plain OHLC or time series, and
var colorstate inside a helper evaluated byrequest.security). This is not fixed in v1.7.0. The two parts have different size: thevar colorhelper state is the smaller one and we plan it first; the helper-parameter history needs a design for evaluating the helper in the requested timeframe's context. We plan to open a pull request for thevar colorhelper state on 2026-10-29. For the helper-parameter history we expect to settle the design by 2026-10-28 and to open a pull request on 2026-11-03.codegen: five fixes for 1.8.0 (late restore, statement-order var init…
codegen: request.security helpers may read the history of a parameter…
luisleo526 commentedon Oct 26, 2026
Both halves of this issue are fixed on main:
var colorstate inside a helper evaluated byrequest.security(the second reproduction): codegen: five fixes for 1.8.0 (late restore, statement-order var initialization, request.currency_rate, helper-local var color, one-line field assignment) #261. Explicit and inferredvar colorhelper state translates, with persistence, transparency andnapreserved. A helper-localvarof any other unsupported type is refused with the new codePF-E3093.f(x) => x[2] - xcalled asf(a)witha = ta.sma(close, 3)now translates; the helper reads the argument's own values on the requested context's bars, one history per call site. Shapes that cannot be sampled (a history offset that is not a non-negative constant, a conditional call, a helper that depends on other helpers' state, a mutable global that cannot be replayed, a parameter type without a lossless history) are refused with located errors,PF-E3094throughPF-E3101.Both ship in codegen 1.8.0. Closing this issue as fixed on main; I will confirm here when 1.8.0 is published.
letiep97 commentedon Oct 28, 2026
Thank you for both fixes. We re-ran our reproductions on main (
11b5ca5, with engine 1.6.1): both cases from this issue now translate and run, and the cases from #226, #227, #228, #230 and #231 now behave as expected.One shape of the first part still fails, with the same
PF-E3011as before. A value derived through a helper that reads its parameter's history translates when therequest.securityexpression is the variable itself or a plain operator on it (b,b * 2,b > 0), but not when the variable is passed to a function, user-defined or built-in, or used in a ternary:CODEGEN 3:10 PF-E3011 request.security helper-parameter history currently requires a direct OHLC/time bar-series bindingThe same error appears with
math.sign(b)orb > 0 ? 1.0 : 0.0as the expression. Since it is the oldPF-E3011rather than one of the new located refusals (PF-E3094toPF-E3101), it looks like a shape the change did not reach rather than an intended limit. Could you reopen this issue or track it separately?