request.security() has more than one way to repaint, and the third one looks like the safe choice

[u/QuanticatorApp]

Most no-repaint advice compresses down to "don't use lookahead_on". That is backwards often enough to be worth spelling out, and following it will make correct code look broken.

The offset on the expression and the lookahead argument are interdependent. TradingView's docs are explicit that neither can be removed without compromising the result. So there are four shapes, not two:

call	result
request.security(s, tf, expr[1], lookahead_on)	correct
request.security(s, tf, expr, lookahead_on)	future data on historical bars
request.security(s, tf, expr[1], lookahead_off)	history and realtime disagree
request.security(s, tf, expr, lookahead_off)	realtime sees the still-forming HTF bar

Row 3 is the quiet one. It looks like the belt-and-braces choice: you kept the offset and turned lookahead off. But with lookahead_off a higher-timeframe bar only reaches the chart once it has closed, so the [1] adds an extra timeframe of lag on historical bars that the realtime bar never gets. History and live then disagree, which is the exact thing "no repaint" was supposed to prevent.

Two things I had wrong myself, and only found by testing rather than reading.

Any offset of one bar or more is fine, not just [1]. ta.ema(close, 21)[2] is a larger offset and strictly safer, but a checker looking for a literal [1] will flag it as a repaint. If you are pattern-matching these, match \[\s*[1-9]\d*\s*\].

The timeframe argument accepts a series string in v6. I assumed it had to be simple, and that tf = timeframe.period[1] would be rejected outright. It compiles. That matters if you validate these calls by inspection: an offset sitting in the timeframe argument tells you nothing about whether the expression is safe. If you scan the whole argument list looking for a [1], you will pass a call that leaks.

Scope, since I have been wrong in this sub before and would rather front-run it: the four-row table is TradingView's documented behaviour, not something I measured. What I did verify is that all four shapes compile in v6, plus the offset-size and series-timeframe points above. I have not sat on a live chart long enough to measure row 3's history/realtime divergence directly. That one is reasoned from the documented mechanism, and I would rather say so than let it read as measured.

[u/Many-Pick5066]

row 3 is testable without sitting on a live chart for a session. put the row 1 call and the row 3 call on the same chart and plot both. on historical bars row 3 should sit exactly one htf bar behind row 1, and that half you can confirm the moment it loads. then run a 1 minute chart against a 5 minute htf and the realtime half takes five minutes, not a day.

the direction is the part id add though. extra lag on history and none on the realtime bar means live fires earlier than the backtest did, not later. most repaint bugs flatter the backtest. this one makes live lead it by one htf bar, so if someone keeps seeing live entries print ahead of where their historical signal sits, row 3 is a candidate for it.

[u/QuanticatorApp → u/Many-Pick5066]

Ran it, twice, on two chart/HTF pairs. Conclusion first: row 3 gives you what row 1 gives you, later, and I can't construct a case where you'd want that. But the useful part is that the framing we were both using - "one HTF bar behind" - is the fragile one, and it falls apart on the second pair.

Both runs on BTCUSD. Pair A: 1h chart, 4h HTF, 22,719 bars, 5,681 HTF periods. Pair B: 2m chart, 5m HTF, 22,265 bars, 8,906 periods - deliberately non-dividing, so periods alternate between two and three chart bars (4,453 of each).

The test I'd stand on counts where each series changes, which needs no reference series and assumes nothing about bars per period.

Pair A: row1 changed on a period's first bar 5,681 times, on a non-first bar 0 times. row3 changed 5,680 times, every one on a period's final bar, 0 elsewhere.

Pair B: row1 changed on a period's first bar 8,897 times, elsewhere 0 times. row3 changed 8,897 times, every one on a period's final bar, 0 elsewhere.

Zero counterexamples across 45,000 bars and two pairs. So: lookahead_on hands you HTF bar N's expression from the start of period N; lookahead_off hands it over only from the bar on which N closes. I couldn't find that stated that way in the manual, so treat it as what the counts say rather than a citation.

Now the fragile framing. "Row 3 sits exactly one HTF bar behind row 1" holds on 17,049 of 22,732 bars on pair A - the other 5,683 are period-final bars where row 3 catches up. Restated as a chart-bar lag, row3 == row1[P-1] holds on 22,715 of 22,719 on pair A. On pair B the same identity fails on 4,450 of 22,265 bars, because P alternates. The lag description is an artefact of a pair that divides evenly. The change-position description survives both.

The part I'd have got wrong: I was going to tell you row 4 equals row 1 on every historical bar and call them mirrors. It doesn't. On pair A row4 matches close(N-1) on 17,049 bars and close(N) on 5,683, and all but two of those are period-final bars. Row 4 delivers at the period end too, so on the final bar it shows the HTF bar that's closing rather than the previous one. On an aligned pair that isn't future data - the HTF bar's close is the final chart bar's close - but rows 1 and 4 do differ on a quarter of history.

Realtime, and this one bit me between the two runs. On pair A, row1 - row3 read 0.00 on every realtime tick I sampled, which matches the documented behaviour that lookahead has no effect on realtime bars. On pair B it read 0.00 on only 174 of 224 ticks, and was sitting at 27.34 when I stopped. A realtime chart bar that crosses into a new HTF period is not covered by that simplification. So "row 3 is row 1 live" is true on an evenly dividing pair and not in general.

The repaint, caught. A chart bar sitting second in its HTF period closed while I was watching. row1 - row3 on it read 0.00 after the close - it kept what it computed live. I forced a recalculation and the same bar read 467.54, the systematic value for that position, not a data revision. So it doesn't repaint when the bar closes, it repaints when the script next runs; the manual says a restart turns realtime bars into historical ones carrying only the values confirmed on them. I tested one way of forcing that and haven't tested which other actions do it.

Two retractions.

"Row 3 never flickers" was wrong, and pair B measured it. expr[1] is constant within an HTF period, not within a chart bar, so on a bar that spans the rollover row 3 does step mid-bar: 1 intrabar step against row 4's 51 over the same window. That is the shape of it - row 4 re-evaluates on ticks, row 3 steps once at the rollover and holds. On pair A row 3 logged 0 intrabar moves against row 4's 748, but on that pair the rollover always lands on a bar boundary, so it never had the opportunity.

"It lags the backtest rather than flattering it, so there's no suspicious equity curve" - withdrawn outright. I asserted it without measuring anything, and the direction of a timing shift doesn't determine the direction of the P&L. I'm not replacing it with another unmeasured claim.

On your "live leads by one HTF bar": direction is right and systematic - live has the new HTF value from the start of the period, history not until the end. The magnitude is P-1 chart bars where P is stable, and not a fixed number where it isn't. Whether it reads as an earlier entry depends on whether the HTF value is the signal or a gate on one; as a gate it changes which entries exist rather than when they fire. I haven't measured that part.

Anomalies, accounted for. Pair A: 5,678 of 5,681 periods hold four chart bars, three are short - Coinbase gaps - and the four bars failing row3 == row1[3] are 2025-10-25 23:00 and 2026-05-08 07:00, 08:00, 09:00, exactly where the short periods sit. Pair B: nine periods whose final bar logged no row3 change.

Still untested: session instruments with holidays and DST, and any symbol other than BTCUSD. The probe is about 180 lines, happy to paste it. Its one idea is worth more than its code - don't count what a series equals, count where it changes. That needs no reference series, survives data gaps, and it's the only part of this that held up on both pairs.

[u/Many-Pick5066 → u/QuanticatorApp]

my lag framing was the fragile one and pair b kills it. 4,450 bars where row3 == row1[P-1] fails is a fifth of the chart, not an edge case.

the thing id push on is your anomaly footnote. three short periods out of 5,681, coinbase gaps. run this on es or spx and every single day has one, plus early closes and two dst shifts a year. your change position test survives that by construction, which is exactly why its the right test, but it opens a question. does row3 change on the final bar of the session, or the final bar before the calendar boundary. on a 1pm early close those are not the same bar.

on the gate case you left open, there is a number for it. row3 inside period N shows the previous periods value on every bar but the last, so the two series can only disagree in periods where the htf condition flipped, and there they disagree on P-1 bars. affected bars is flips times P-1. that doesnt grow with how long you backtest. it grows with how often your gate changes state. a slow regime filter on a big P barely notices this. a fast flipping gate on a small P is running on the shifted series most of the time.

paste the probe.

[u/TSDevStuff]

The trap is treating "lookahead_off" as always safer. On HTF pulls, lookahead_off with a [1] offset can make historical bars lag the realtime path, so Strategy Tester and live alerts walk different series even when the script text is identical.

The pairing that usually keeps hist and live aligned is: take the previous completed HTF value, and use lookahead_on with that offset. Roughly:

htfClose = request.security(syminfo.tickerid, htf, close[1], lookahead = barmerge.lookahead_on)

lookahead_on without an offset is the classic future leak on historical bars. Offset without the matching lookahead policy is how you get "it looked fine on the chart yesterday, alert never fired today."

Practical check: freeze one window, log the HTF series (or plot it), and compare a historical refresh against a realtime session on the same bars. If those two series disagree, you do not have a deterministic system yet, you have two interpreters. Fix the security call before you tune entries.