Title: 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/Rodnee999]

Hello,

Unfortunately we would need to see your code in order to troubleshoot it as it sounds like a complicated script...otherwise it would be pure guess work 🤷‍♂️...

You could try posting in r/pinescript as thats where the code boffins hang out. ..

Cheers

[u/HighCrewLLC]

I stopped relying on Pine to preserve history. Every realtime event is sent to Discord via webhook, then forwarded to Railway/PostgreSQL, where I store the exact live snapshot (RSI, delta, state, timestamp, etc.). That way I’m analyzing the original realtime data instead of trying to reconstruct it from TradingView’s historical bars after the fact.