Repository navigation
request.security: a helper-history value passed to a function or a ternary still fails with PF-E3011 (follow-up to #229) #287
Description
Summary
Follow-up to #229, which is closed. Since that fix, 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. It still fails when the variable is passed to a function, user-defined or built-in, or used in a ternary.
The error is the old PF-E3011, not one of the located refusals added with the fix (PF-E3094 to PF-E3101), so it looks like a shape the change did not reach rather than an intended limit. I raised it in a comment on #229 on 28 October and am opening it separately so it can be tracked while #229 stays closed. cc @luisleo526, since you fixed #229.
Versions
pineforge-codegen 1.9.1; also 1.9.0, and main 11b5ca5 when I commented on 28 October. The error comes from the front end, so it should not depend on the platform.
Reproduction
//@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))
if c > 0
strategy.entry('Long', strategy.long)
CODEGEN 3:10 PF-E3011 request.security helper-parameter history currently requires a direct OHLC/time bar-series binding
The location points at the helper f, not at the request.security call. Changing only the expression in the call:
Expression passed to request.security |
1.9.1 |
|---|---|
b |
translates |
b * 2 |
translates |
b > 0 |
translates |
g(b) (user-defined function) |
PF-E3011 |
math.sign(b) (built-in) |
PF-E3011 |
b > 0 ? 1.0 : 0.0 (ternary) |
PF-E3011 |
Expected
The three failing expressions translate as the three plain ones do. If this is an intended limit, a located refusal that names the unsupported part would help.
Workaround
None that keeps the meaning: computing the value outside request.security matches only when the requested timeframe is the chart's.
Activity
luisleo526 commentedon Nov 1, 2026
Thank you for the detailed report. We are checking each case against TradingView's behaviour and our source, and will post a result for each case in this issue by the end of 2026-11-03 (UTC). If a case needs longer, we will say so here with the reason.
luisleo526 commentedon Nov 3, 2026
Thank you for the report. This is the result for each case on the released pineforge-codegen 1.10.0. The fix is planned for the next release (1.10.1), as the 1.10.0 release notes list for this issue.
request.securitybb * 2b > 0g(b)(user-defined function)PF-E3011, pointing at the helperfrather than at therequest.securitycallmath.sign(b)(built-in function)PF-E3011b > 0 ? 1.0 : 0.0(ternary)PF-E3011The three failing expressions are defects, not an intended limit: the check that follows the helper's history keeps working through operators on the value, but stops when the value is passed to a function, user-defined or built-in, or used in a ternary, and falls back to the older
PF-E3011refusal. They are expected to translate as the three plain forms do. The fix is planned for the next release (1.10.1); the issue stays open until it is released. For the specific pure helperg(v) => v * 2shown here, inlining it asb * 2uses the supported translation form. Moving the computation outsiderequest.securitycan change its timeframe semantics and is not a general workaround.luisleo526 commentedon Nov 6, 2026
The fix, merged in #327 (commit 08261a2), is on main and not yet released; it ships in the next release and the issue closes then. The reported helper-history composition now translates and preserves the requested-history values through the helper and request context. The report does not provide a numeric TradingView stream for this example, so this confirms the composition without claiming a TradingView trade comparison.
luisleo526 commentedon Nov 8, 2026
Update: the helper-history composition fix is on main; the next release is 1.11.0.
The composition was checked on 2026-11-06 on main after #327 (
08261a24) landed, as reported in our earlier comment. It was not re-run today; that comment identifies the fix commit but does not record the exact tested main commit.request.securitybb * 2b > 0g(b)(user-defined function)08261a24)math.sign(b)(built-in function)08261a24)b > 0 ? 1.0 : 0.0(ternary)08261a24)This confirms the composition described in the report. The issue provides no numeric TradingView stream for it, so we are not claiming a trade-list comparison.
This is fixed on main and ships in 1.11.0, whose publish target is 2026-11-10. This issue will be closed when that release is published.
Clarify unreleased fixes and numeric helper documentation (#353)
luisleo526 commentedon Nov 9, 2026
Fixed in v1.11.0. The fix is part of the v1.11.0 release; its test modules pass on v1.11.0 together with the current engine.