Multi-day request.security (N>1 day, e.g. "3D"/"5D") delivers the developing period close on every chart bar instead of the last-confirmed period close (Daily "D" is correct) in v6.5.1

[danielmayerfrank]

Follow-up to #65 (multi-day calendar-vs-trading-day grouping), which was fixed by the trading-day-aware aggregation in v6.5.1. After that fix, multi-day periods are now grouped correctly — but the value delivered by request.security(..., "ND", expr, lookahead=barmerge.lookahead_off) for N > 1 day is still wrong:

• For "D" (Daily), request.security(syminfo.tickerid, "D", close, lookahead=barmerge.lookahead_off) correctly delivers the last confirmed daily close, held constant across the chart bars of the developing day, updating once per session. This matches TradingView.
• For "3D" / "5D" (any N-day, N>1), the same call delivers a value that changes on ~99% of chart bars and equals the current chart bar's own close ~99% of the time — i.e. it tracks the still-forming (developing) period close rather than holding the last-confirmed multi-day period close. On TradingView, the same expression with lookahead_off holds the last confirmed N-day close across the developing period.

Periods themselves ARE being formed correctly (a timeframe.change("5D")-style new-period flag fires cleanly every 5 trading days / 7 calendar days at a consistent anchor) — so this is specifically a value-delivery problem in the multi-day path, not a grouping problem.

To Reproduce

Install PyneCore 6.5.1:

python -m pip install -U pynesys-pynecore==6.5.1 typer

Run these minimal probes on any intraday (e.g. 15-minute) futures feed, supplying the N-day series via --security:

probe_daily.py (CORRECT — held):

python

"""@pyne"""
from pynecore.lib import close, plot, request, script, syminfo, barmerge

@script.indicator("probe_daily", overlay=False)
def main():
    htf = request.security(syminfo.tickerid, "D", close, lookahead=barmerge.lookahead_off)
    plot(htf, title="htfCloseD")

probe_3d.py (BUGGY — developing):

python

"""@pyne"""
from pynecore.lib import close, plot, request, script, syminfo, barmerge

@script.indicator("probe_3d", overlay=False)
def main():
    htf = request.security(syminfo.tickerid, "3D", close, lookahead=barmerge.lookahead_off)
    plot(htf, title="htfClose3D")

Run each (example):

pyne -w <workdir> run probe_daily.py <feed>_15m.ohlcv --security D=<feed>_15m --plot daily.csv
pyne -w <workdir> run probe_3d.py    <feed>_15m.ohlcv --security 3D=<feed>_15m --plot 3d.csv

Then count how often the plotted HTF value CHANGES between consecutive chart bars, and how often it equals the chart bar's own close.

Observed behavior

On a ~8,800-bar 15-minute futures feed (NQ, tested with timezone="Etc/GMT-2" and timezone="America/Chicago" — identical result):

Period | HTF value changes (of ~8,800 bars) | HTF == current chart close | New-period flag fires -- | -- | -- | -- "D" | 96 (≈ once per trading session) | ~0.1% | once per session (correct) "3D" | ~8,696 (≈ every bar) | ~98.9% | every 5 trading days (correct) "5D" | ~8,696 (≈ every bar) | ~98.9% | every 5 trading days (correct)

"3D" and "5D" produce identical developing-close output. The new-period boundary detection for "5D" fires exactly every 5 trading days (7 calendar days) at a consistent anchor — confirming the period grouping is correct, while the delivered value is the developing close rather than the confirmed period close.

Expected behavior

request.security(syminfo.tickerid, "ND", expr, lookahead=barmerge.lookahead_off) for N > 1 day should deliver the last confirmed N-day period value, held constant across the developing period and updating only when a new N-day period confirms — exactly as it already does for "D", and as TradingView does. Currently only N=1 ("D") behaves this way; N>1 delivers the developing value.

Additional context

This appears to be in the multi-day path touched by the #65 fix (bf2cf69, trading-day-aware D/W/M aggregation): grouping was corrected, but the N>1-day branch returns the in-progress period value instead of the last-confirmed one. The "D" branch is unaffected and correct. Happy to provide a small anonymized CSV extract around any boundary if useful.

Environment

• pynesys-pynecore==6.5.1 (CLI dependency typer installed separately)
• Chart timeframe: 15 minutes
• HTFs tested: "D" (correct), "3D" and "5D" (developing-value bug)
• lookahead: barmerge.lookahead_off
• Native HTF supplied via --security
• Symbol: futures (NQ), tested under Etc/GMT-2 and America/Chicago — identical