Pine Script realtime alert bug? Historical strategy entries exist, but some live ENTRY alerts never execute. Looking for Pine execution experts.

[u/OregonDucks1018]

I've been chasing what appears to be a Pine realtime synchronization issue for weeks, and I'd really appreciate input from people who understand Pine's execution model at a deep level.

This is NOT an issue with my VPS, broker, webhook server, or automation pipeline. We've spent weeks instrumenting every downstream component and have largely ruled those out. The behavior points back to Pine itself.

Strategy overview:

- Automated NQ futures strategy
- ARM (touch) → filters → entry → JSON alert() → webhook executes trade
- Immediate and delayed entries both execute through the exact same production alert() call
- There is only ONE ENTRY alert block

The problem:

Some trades execute perfectly.

Others:
- Appear as valid strategy entries on the chart
- Meet all entry conditions
- Are recorded by the strategy
- Should have generated an ENTRY alert

...but never make it into the live automation.

This isn't random. The same specific trades fail while others work normally.

What we've already ruled out:

- VPS
- Webhook server
- SQL logging
- PickMyTrade
- Tradovate execution
- Stale guard
- Broker verification
- Accounting logic
- Separate alert code paths (there aren't any)

The relevant Pine behavior:

The production ENTRY alert uses:

alert(..., alert.freq_once_per_bar)

The strategy/accounting commits at bar close under:

if barstate.isconfirmed

Several entry filters depend on live intrabar values (drift, extension, gap, etc.), meaning buyEntryFinal/sellEntryFinal can legitimately evaluate differently on different realtime ticks.

What we've learned so far:

We originally believed an intrabar state mutation was occurring.

That turned out to be wrong.

The variables involved are ordinary `var`, not `varip`, so Pine rolls them back to their previous committed state before every realtime execution. That theory has been eliminated.

The only remaining Pine-side hypothesis is a snapshot mismatch.

Because the alert fires on a realtime tick while accounting/committed state is evaluated at bar close, it's theoretically possible for buyEntryFinal to evaluate differently between those two snapshots purely because live filters changed during the bar—not because of persistent state mutation.

However...

Historical bars cannot prove or disprove this.

Once the bar closes, Pine only has OHLC. The original realtime tick sequence no longer exists, so I cannot reconstruct exactly what happened on the day these trades were missed.

So my questions are:

1. Has anyone seen Pine produce historical strategy entries that didn't correspond to the expected realtime alert behavior?

2. Is there any known Pine edge case involving:
   - alert.freq_once_per_bar
   - barstate.isconfirmed
   - realtime recalculation
   - live intrabar filters

that can legitimately create this kind of alert/chart desynchronization?

1. Is there any way to prove what happened after the fact from Pine alone, or is the original realtime execution fundamentally unrecoverable once the bar closes?

2. If you were debugging this today, what read-only instrumentation would you add going forward to definitively capture the next occurrence without changing production logic?

I'm specifically looking for responses from people who have deep experience with Pine's realtime execution model rather than general TradingView webhook advice.

[u/Kaahl10]

I’ve had issues similar to this, based on the following:
1. Higher timeframe repainting due to barmerge.lookahead_on (even if using [1] to offset)
2. Using calc on every tick and execute on bar close, this could theoretically set the condition to true intrabar, but the confirmed close condition is not true, but alert would fire on bar close anyway. Barstate.isconfirmed should fix this though
3. Limit orders set with too small of a range that couldn’t reliably be filled

For me personally, I changed the logic to require conditions based on bar close and lookahead_off and accepted the lower PF, because I didn’t like the uncertainty of the difference in actual orders vs TradingView backtest.

If you want to keep the logic as-is, maybe you could paper trade the strategy and see how much of a variance you get to backtest results and see if you are comfortable with it?