fix(longbridge): keep GTC/GTD orders alive on transient Expired status

[FaintGhost]

Problem

Longbridge reports US-equity GTC/GTD limit orders as Expired (status 16) between trading sessions — a transient venue state that reverts to New once the market reopens. The broker adapter mapped Expired → Inactive, and the UTA order-sync loop treats any non-Submitted state as terminal (rejected). The order was then dropped from the pending queue and never re-observed.

Live evidence (longbridge-main account): three GTC limits submitted together:

• ARM GTC limit filled on time and was recorded correctly
• NVDA GTC limit filled later at its limit price, but UTA had already marked it rejected — the fill was invisible to UTA
• NET GTC limit stayed open at the broker (still visible in the official Longbridge app), but UTA marked it rejected

So the UTA state machine and the broker disagreed, and the discrepancy was only discoverable by querying the broker directly.

Fix

Disambiguate Expired with the order's timeInForce:

• Expired + Day (1) → Inactive (a Day order genuinely expires unfilled at close)
• Expired + GTC (2) / GTD (3) → Submitted (transient between sessions; keep the order in the pending queue so the sync poller keeps observing it until it fills, cancels, or truly terminates)

makeOrderState now accepts and forwards timeInForce; mapOpenOrder supplies it from the broker response.

Verification

• 73/73 vitest tests pass in LongbridgeBroker.spec.ts, including 4 new cases covering the Expired/TIF matrix
• No API/UX surface changed; behavior only affects the order-status projection used by sync reconciliation

[vercel]

@FaintGhost is attempting to deploy a commit to the luokerenx4's Team Team on Vercel.

A member of the Team first needs to authorize it.

[luokerenx4]

Thanks for the detailed live evidence here — the GTC failure mode is convincing, especially the order that later filled after UTA had already made the transient Expired status terminal.

Before we reproduce this on a maintainer-owned branch, could you help us pin down a few Longbridge-specific semantics? We do not currently have a Longbridge test account, and this is a trading state-machine boundary where we would rather use venue evidence than infer behavior.

1. GTC transition evidence. If you still have sanitized observations, could you share the relevant fields from orderDetail across the transition (for example status, timeInForce, expireDate, updatedAt, executedQuantity, and executedPrice) for one order that went Expired → New/Filled? Please omit account identifiers and credentials.
2. GTD behavior. Have you observed the same between-session Expired → New transition for a GTD order, or is the GTD part inferred from GTC? A GTD order must eventually become genuinely expired on its configured date, so mapping every Expired + GTD to Submitted would appear to keep a truly expired order pending forever unless we also inspect expireDate.
3. Unknown/missing TIF. The adapter's raw order shape currently requires timeInForce. Is there a real Longbridge response where it is Unknown/missing for an expired order? If not, we are inclined to keep the workaround narrow: only explicitly verified long-lived TIF values should override Expired.
4. Fill fidelity. In the later-filled NVDA response, did orderDetail provide executedQuantity as well as executedPrice? The current adapter maps the price but not executedQuantity → order.filledQuantity, so fixing the terminal-state error alone may recover the fill status while still leaving UTA's fill/cost-basis record incomplete.
5. Safe acceptance path. Does Longbridge paper/demo exhibit this same after-hours status transition? If so, a minimal reproduction sequence and expected cleanup would be very helpful. If it only occurs on live accounts, we will treat your sanitized observation as venue evidence and keep our own verification offline/read-only rather than submit real-money test orders.

Our external contribution policy means we will not directly merge a cross-repository trading-surface branch; we use strong external PRs as implementation proposals and reimplement accepted changes on a maintainer-owned branch. Your report and analysis will be credited in CONTRIBUTORS.md if this lands. The core GTC diagnosis looks valuable — the questions above are about choosing a boundary that fixes the observed bug without turning real expirations into permanently live UTA orders.

[FaintGhost]

Thanks for the detailed review — all five points are fair, and the code has been revised to address them. To get you venue evidence (not inference), I queried the live account's SDK directly and sanitized the response. All evidence is from longbridge-main (real-money account, no credentials/ids included).

On the revised commit (e69f16a): I've narrowed the Expired override to GTC only, and added executedQuantity → order.filledQuantity mapping. Replying per-point:

---

1. GTC transition evidence

Direct TradeContext.orderDetail(...) sanitized fields (status = Longbridge OrderStatus enum, timeInForce = TimeInForceType enum):

Order	status	timeInForce	qty	executedQuantity	executedPrice
NVDA (filled later)	5 Filled	2 GTC	3	3	218.99
NET (still open)	1 NotReported	2 GTC	1	0	—
ARM (filled on time)	5 Filled	2 GTC	2	2	286.68

I did not capture a Expired → New/Filled snapshot at the moment of the transient state — UTA records only the derived status string, not the raw broker response, so the raw Expired moment wasn't persisted locally. What I have is: (a) the order was rejected by UTA at 00:03/00:04, and (b) the same orders later resolve to Filled/NotReported. The terminal-state misclassification is therefore observed from both ends, but the intermediate raw Expired payload would need the broker to be re-polled during an after-hours window to capture in full. Happy to add a minimal instrumentation to capture it if you want that snapshot.

2. GTD behavior — you're right, it was inferred. I had no GTD observation. Per your guidance I've narrowed the override to timeInForce === 2 (GTC) only; GTD(3) now returns Inactive, and Unknown/missing TIF stays conservative. The code comment and tests now state this explicitly. So: GTC is venue-observed, GTD is not.

3. Unknown/missing TIF. In the three observed responses, timeInForce was consistently 2 (GTC). I have not observed a real Unknown/missing TIF on an expired order — hence the conservative default (Inactive) you'd prefer, which is now the code path for anything that isn't GTC.

4. Fill fidelity — confirmed, and fixed. orderDetail does return executedQuantity (NVDA 3, ARM 2 above), but the adapter mapped only executedPrice → avgFillPrice and silently dropped executedQuantity. I've added executedQuantity → order.filledQuantity in the same commit, so a recovered fill now carries both qty and price (cost-basis complete). This was a real gap beyond the terminal-state bug — thanks for catching it.

5. Safe acceptance path / paper. These observations are from a real-money live account. I have not verified the same after-hours transition on Longbridge paper/demo — I don't have GTC test orders on the paper account. I'd treat the live observation as venue evidence and, if it helps, I can submit a small GTC order on the paper/demo account to reproduce it without real-money exposure (say a far-OTM limit that would never fill). Let me know if you'd like me to run that.

The account-side evidence is intentionally kept out of the repo — happy to provide more sanitized field dumps if useful. Thanks again for the tight review; the GTD narrowing and the fill-quantity gap were both good catches.