barstate.isconfirmed returns wrong value inside request.security subprocess

[Zombajo]

Summary

When request.security spawns a subprocess to compute HTF features, barstate.isconfirmed returns wrong values inside the subprocess. Strategies that gate logic on barstate.isconfirmed (e.g., "execute only on confirmed bar close") behave incorrectly when used in combination with request.security.

Filing for verification — would appreciate confirmation that our reading of the intended semantics is correct.

Symptom

Any strategy that combines:

• request.security calls to compute higher-timeframe features
• Logic gated on barstate.isconfirmed

produces wrong results inside the subprocess. The barstate.isconfirmed value inside the subprocess does not reflect the confirmation state of the parent timeframe correctly.

Suspected location

pynecore/core/security_process.py lines ~150-160 (subprocess return path for request.security evaluation).

Reproduction

Minimal script:

from pynecore.lib import strategy, request, ta, barstate

@strategy("isconfirmed_repro")
def main():
    htf_close = request.security(syminfo.tickerid, "60", close)
    if barstate.isconfirmed:
        # log: bar_index, htf_close, barstate.isconfirmed
        # observed: barstate.isconfirmed value inconsistent with parent TF
        pass

Expected: barstate.isconfirmed reflects parent timeframe's bar confirmation state. Observed: inconsistent / wrong values during the subprocess return phase.

Proposed fix direction

The subprocess that evaluates request.security needs to thread the parent timeframe's confirmation state correctly back into barstate.isconfirmed when the result is consumed in the parent process. We've applied a local patch at security_process.py:150-160 that resolves the symptom for our test cases — happy to share the patch and test fixtures if useful.

Validation evidence

Discovered during a Python↔Pine bridge validation arc on a futures strategy using 1m execution timeframe with 1h request.security confirmation gates. With the local patch applied, PyneCore output matches TradingView strategy tester within tolerance for the same Pine source.

Verification request

Could you confirm whether this is a real bug or whether we have misunderstood how barstate.isconfirmed is intended to behave inside request.security subprocesses? Happy to share our local patch as a starting point for a PR if you'd like.

Environment

• PyneCore version: [check with pip show pynecore — likely v6.4.5 if upgraded]
• Python version: [check with python --version]
• OS: Windows 11

Related

This was discovered as part of the same multi-day Pine v6 ↔ PyneCore bridge validation effort that produced issue #48 (percent-commission underreport, fixed in v6.4.5 — thanks for the fast turnaround on that one).

[wallneradam]

Thanks for the detailed report and the reproduction — it was very helpful for triaging this.

After re-investigation, this is not a bug, it is a missing feature. The request.security subprocess is historical-only by design in the currently released codebase: it uses a static OHLCVReader (no live tick feed reaches the HTF subprocess), and _get_confirmed_time in the chart loop only advances the subprocess to the previous closed period. Every bar the subprocess actually runs is therefore a closed historical bar, so barstate.isconfirmed = True inside the subprocess is consistent with that mode — not a misbehavior of that one line.

The TV-divergence you observed (isconfirmed=false on the real-time HTF bar) is the visible symptom of the live mode being absent rather than of a wrong assignment. A proper TV-equivalent fix requires three pieces together — a chart→subprocess is_closed channel, a _get_confirmed_time that advances to the open period in real-time with a chart-side return-value cache to preserve lookahead_off semantics, and an actual live OHLCV feed into the subprocess. A patch to security_process.py:150-160 alone, without the rest, would only trade one inconsistency for another, so we'd rather not land that.

Live request.security support is being built on a development branch and will land as a feature in a future release. Closing this issue as not-a-bug — thanks again for taking the time to write it up.