Hey, found what looks like a regression in modify order handling. We've been running a live chase/re-peg strategy on mainnet since early 2026 that periodically modifies resting GTC orders, and this used to work fine even when the new price crossed the spread (executed as taker). Recently we started seeing modify calls get rejected with a "Post only" error whenever the new price crosses, even though tif is explicitly set to "Gtc" — and worse, the original resting order gets canceled as a side effect of the failed modify, not just the replacement. Reproduced this cleanly on testnet with a minimal script (attached, hl_modify_test.py), full writeup with repro steps and actual/expected behavior in hl_bug_report.txt. Wanted to check here whether this is intended (i.e. modify always enforces ALO regardless of tif) or a bug, since it's not documented either way.
Hey, found what looks like a regression in modify order handling. We've been running a live chase/re-peg strategy on mainnet since early 2026 that periodically modifies resting GTC orders, and this used to work fine even when the new price crossed the spread (executed as taker). Recently we started seeing modify calls get rejected with a "Post only" error whenever the new price crosses, even though tif is explicitly set to "Gtc" — and worse, the original resting order gets canceled as a side effect of the failed modify, not just the replacement. Reproduced this cleanly on testnet with a minimal script (attached, hl_modify_test.py), full writeup with repro steps and actual/expected behavior in hl_bug_report.txt. Wanted to check here whether this is intended (i.e. modify always enforces ALO regardless of tif) or a bug, since it's not documented either way.