[Bug] Improper Handling of "Canceled" Order Status During Relayer Halt

[usmanshahid86]

There is a critical discrepancy between the actual order state and the UI feedback when the relayer is in a "halt" status. Currently, the frontend incorrectly reports a successful order placement even when the relayer has rejected and canceled the transaction.

Identified Issues:

Status Sync Latency: The frontend takes 2–3 seconds to transition from "Healthy" to "Halt," creating a window where users can still attempt to place orders.

False Positive UI Feedback: When an order is placed during a halt, the relayer returns an order_status == "canceled". However, the frontend currently treats the receipt of a transaction hash as a success, displaying "Order placed successfully."

Failure to Parse Cancellation Reason: The relayer provides a specific cancellation reason in the response, but the frontend is not currently surfacing this to the user.

Requirements:

Enhanced Status Checking: The frontend must explicitly check the order_status from the transaction_hash method.

Conditional UI Feedback: * If order_status == "settled", show "Order placed successfully."

If order_status == "canceled", show "Order failed" or "Order rejected by Relayer."

Error Detail Integration: Extract and display the "cancellation reason" provided in the relayer's response within the error toast or notification.

Universal Application: This logic must be applied across:

Trader Orders (Open/Close)

Lend Orders

Technical Context: The root cause is that the frontend assumes a valid transaction response equals a successful order. It needs to be updated to wait for/verify the specific state within that response before confirming success to the user.

Action Item: Investigate why the canceled state is currently being bypassed in the detection logic and ensure the UI reflects the real-time health of the order.