Skip to content
ChartTailor
WorkServicesPricingField NotesAbout Start a build
← Pine Discoveries

Replay ticker IDs can carry more context than a plain symbol

Ticker strings in TradingView can include replay and modifier context, so Pine scripts should avoid naive symbol parsing.

A ticker ID looks like a string until it stops behaving like a simple string. In normal chart use, NASDAQ:AAPL or BINANCE:BTCUSDT feels easy to reason about. In replay mode or with modified ticker contexts, the script may be dealing with a ticker ID that carries extra context. If the code treats that value as a plain exchange-symbol pair, it can break in ways that are hard to diagnose.

This one matters because replay ticker context is exactly the kind of obscure issue that wastes hours. The script works historically. It works on crypto. Then it flattens, misrequests, or behaves strangely in replay on stocks or futures.

Why this catches people

The bad assumption is building ticker IDs by string concatenation. A script takes syminfo.prefix, syminfo.tickerid, or syminfo.ticker, combines them with a session choice, and assumes the result is a normal symbol. That may work until replay adds a token or until the chart context includes modifiers the string code did not expect.

The more robust approach is to let Pine’s ticker functions manage context. ticker.new(), ticker.standard(), and ticker.inherit() are not just convenience functions. They help preserve or remove ticker modifiers deliberately.

The Pine bit

The detail that stuck with me is that replay can wrap symbol context in a way that is not equivalent to a normal ticker string. If a script constructs a new ticker from the wrong piece, it may accidentally include or lose replay context. In one practical pattern, ticker.inherit() can be used to build a ticker that takes desired modifiers while avoiding the part of the current replay ticker that should not be carried forward.

The exact construction depends on what the script is trying to preserve: session, adjustment, synthetic chart type, or standard price context. That is why I avoid one-size-fits-all string fixes.

//@version=6
indicator("Ticker context idea", overlay = true)

extendedBase = ticker.new(syminfo.prefix, syminfo.ticker, session.extended)
stableSymbol = ticker.inherit(extendedBase, syminfo.ticker)
requestedClose = request.security(stableSymbol, timeframe.period, close)

plot(requestedClose)

Why it can survive a quick review

This can slip through review because the broken context may not appear in the first test. Crypto symbols, standard charts, and historical calculation can all pass. Replay mode can expose the issue because the symbol context is no longer just the plain market identifier the author had in mind.

It also survives because ticker strings are easy to print and inspect casually. Seeing something that contains the expected symbol does not prove the constructed ticker is the right one for a request. The modifiers matter.

How I handle it in builds

When I write request-heavy scripts, I keep ticker construction in one place. If the script needs standard prices, I build a standard ticker deliberately. If it needs extended-session data, I build that deliberately. If it needs to inherit chart modifiers, I use the helper designed for that job. I do not scatter string concatenation through the script.

I test ticker-sensitive scripts in replay. Replay is not only a visual backtesting tool. It is a useful way to reveal whether the script’s symbol handling is too naive.

Where this shows up

One reason I keep this as a separate discovery is that the bug looks irrational until you know ticker IDs can carry replay context. A user sees the correct symbol on the chart and assumes any request for that symbol should behave normally. The script author has to remember that the visible label and the internal ticker context are not always the same level of detail.

I avoid using string tests as validation. Checking whether a ticker string contains “AAPL” or “BTCUSDT” does not prove the request is correct. The script should validate by comparing returned values across normal mode, replay mode, and the intended session context. Behaviour is the test, not string familiarity.

In implementation, I keep a small debug mode for ticker-sensitive builds. It can show the chart ticker, requested ticker, session choice, and a simple comparison value. That debug mode is not for normal users, but it is invaluable when replay behaves differently from historical calculation.

I prefer helper functions that return named ticker IDs rather than inline expressions. A function called getExtendedTicker() or getStandardTicker() tells the reader what context is intended. If a replay issue appears later, the fix has one obvious home instead of ten request calls.

How I test it

I test ticker logic by comparing requested values in normal mode, replay mode, and any required session mode. If the ticker construction is fragile, one of those contexts usually exposes it. The symbol label alone is not enough proof.

Before ticker context drives a signal, I test context changes before signal logic. Replay, extended hours, standard tickers, and synthetic tickers should all return understandable data before any trading condition is judged. Otherwise a signal bug may really be a symbol-context bug.

The final implementation habit is to keep a normal-symbol fallback during testing. If a request fails only in replay or only after adding session modifiers, the fallback tells me whether the signal logic is fine and the ticker context is the real problem. That prevents a symbol bug from turning into a needless rewrite of the indicator.

I test the same request before starting replay, during replay, and after leaving replay. If only the middle state fails, the context token is the first suspect.

That narrow comparison prevents a replay-specific issue from being mistaken for a bad trading condition or a broken data feed.

Checks before I trust it

  • Avoid splitting or rebuilding ticker IDs with plain string assumptions.
  • Use ticker helpers to preserve or remove session and chart modifiers deliberately.
  • Test replay mode when a script constructs tickers for request.security().
  • Check stocks, futures, and crypto separately because symbol context can differ.
  • Keep ticker construction centralized so future fixes are not scattered.

The point I keep coming back to is that a ticker ID can carry context, not just a name. Pine scripts that respect that context survive replay and synthetic chart cases much better.