porcelaincodeandPier Code 326f145322 fix(stream): a refused print still advances the schedule clock ...

In plain words: a timer set for 09:20 on a live tick stream now fires at
09:20, even when the row that revealed 09:20 carried no price. It used to
wait for the next print the session accepted, which for an index that
only ticks on a trade could be minutes later.

A row with ltp == 0 and no two-sided book appends no event, and
push_tick still returns 0, but its timestamp proves the market reached
that instant. The stream now advances that symbol's clock on such a row
and fires every alert and timer due by then inside the push. Orders the
timer submits are routed to their instrument at once and match from its
next print, the rule submission_idx already applied across instruments.
Intents such as enter() and close_position() name no symbol, so they are
held for that symbol's next trade event rather than left on the queue for
whichever symbol prints first.

The batch runner drops such rows in the Rust merge and cannot fire on
them; the docstring and README say so.

Four tests pin it: an alert fires on a quote-less print with ts_fired at
that instant and not again on the next print; a timer fires once per
symbol whichever row reveals the time; an order submitted between prints
is already resting and fills on the next print; an intent queued between
prints closes its own symbol, not the one that prints first. All four
fail with the old behaviour.

Version 0.13.4.

Co-authored-by: Pier Code <no-reply@piercode.com>

2026-09-10 22:33:07 +05:30

..

python

fix(stream): a refused print still advances the schedule clock

2026-09-10 22:33:07 +05:30

test_fill_timing.rs

perf(bindings): read NumPy buffers instead of duplicating them

2026-09-09 22:13:04 +05:30

test_indicators.rs

feat(api)!: drop the Py prefix from every public class; clear all warnings

2026-08-12 07:50:08 +05:30

test_portfolio.rs

perf(bindings): read NumPy buffers instead of duplicating them

2026-09-09 22:13:04 +05:30