Hidden or reloaded scripts are a useful test for realtime assumptions

A script that behaves differently after being hidden, reloaded, or reactivated is uncomfortable to debug because the chart does not show the missing part. The visible output changes, but the cause may be the script’s relationship with realtime calculation, intrabar state, or drawing updates. That makes it tempting to blame a platform mystery and move on.

I started keeping a note on this because the useful lesson is more practical than the speculation. If a script only behaves correctly while it has been continuously active, that is a clue. It means the script may be depending on realtime information that cannot be reconstructed from the completed bars.

Why this catches people

The mistake that looks harmless is to assume that hidden, inactive, reloaded, and continuously running scripts all have the same state. They may produce the same result for simple bar-close logic. They may not produce the same result for logic that relies on intrabar updates, varip, realtime drawing mutation, or alerts that fired during a forming bar.

I do not like building on assumptions about exactly how the platform schedules an inactive script. That can change, and it is not the real design point. The real point is that a robust script should be able to explain which parts are rebuildable from history and which parts are live-only.

The Pine bit

The reload test is one of the simplest ways to expose that difference. Watch the script live, note the drawing or signal, then reload the chart. If the output changes, the next question is not “why did Pine lie?” It is “which part of this output depended on realtime state?” Sometimes the answer is acceptable. A live warning may be useful even if it disappears later. A confirmed historical signal should not depend on that kind of state.

This is especially important for scripts that manage arrays of drawings. Object IDs, intrabar updates, and state flags can create output that feels persistent while the session is active. After reload, the script has to rebuild from the available bars.

liveOnly = barstate.isrealtime and not barstate.isconfirmed
confirmedOnly = barstate.isconfirmed

How I handle it in builds

I build around this by separating durable signals from live traces. Durable signals should come from confirmed conditions and rebuild cleanly. Live traces can be drawn differently, labeled differently, or kept out of the historical record. That makes the tool more honest and easier to support when a user says the chart changed after refresh.

The same thinking applies to alerts. If the alert fired from a live-only state, the chart may not later show the exact thing that caused it. The payload and documentation should make that clear.

Where this shows up

A useful debugging habit is to keep a tiny “rebuild marker” in development versions. If a script rebuilds a historical object, mark it one way. If it creates something only during realtime, mark it another way. That quickly reveals which parts of the chart depend on continuous execution.

I do not publish that kind of marker in final client tools, but the habit informs the design. Confirmed levels should rebuild cleanly. Live traces can be allowed to disappear. The user should not have to guess which type they are looking at after refreshing the chart.

This is also one reason I am cautious about scripts that promise perfect historical proof for highly intrabar visual behaviour. If the proof depends on the chart never being reloaded, it is not really historical proof.

How I test it

I test realtime behaviour with a reload test. Watch the script during a live bar, then refresh or reload the chart and compare what survives. The difference tells me which parts were confirmed history and which parts were live-only behaviour.

Checks before I trust it

• Reload after live observation and compare the output.
• Separate confirmed signals from live-only traces.
• Avoid relying on hidden scheduling assumptions as part of the design.
• Be cautious with drawing arrays that mutate during realtime bars.
• Explain live-only alerts when the chart will not preserve the triggering path.

The practical takeaway is that hidden or reloaded behaviour is not just a nuisance. It is a diagnostic. It tells you whether the script is built from history, live state, or a mix of both.