# Inconsistent Order State Misleads Order Status
## Description
The `Order` struct contains an `isActive` flag that indicates whether an order is fillable. This flag is toggled off during order cancellation or successful purchase. However, it remains `true` even after the deadline expires, making the order appear active in the `getOrder` function and related UI logic.
## Risk
**Likelihood**:
* Users interacting with the UI may attempt to buy sold or canceled orders.
* Off-chain systems may misrepresent sold and canceled orders as active.
**Impact**:
* Users will revert on `buyOrder` due to `OrderExpired`.
* Creates inconsistent state between contract logic and off-chain representations.
## Proof of Concept
Create a sell order with a **very short deadline** (e.g., 10 seconds). After waiting for it to expire, call `getOrder()`. It will misleadingly report the status as `"Active"` despite the order being expired and unfillable.
```solidity
// 1. Assume msg.sender is a seller with enough wETH approved for this contract
orderBook.createSellOrder(
address(wETH), // _tokenToSell
1e18, // _amountToSell (1 wETH)
100e6, // _priceInUSDC (100 USDC)
10 // _deadlineDuration = 10 seconds
);
```
Wait for **10+ seconds** (until after the deadline), then call:
```solidity
string memory details = orderBook.getOrder(1);
```
Expected output (current behavior):
```
isActive: True
```
But the order is no longer valid due to deadline expiry.
## Recommended Mitigation
- Make `isActive` false when `deadlineTimestamp` is exceeded or remove the `isActive` logic totally and rely on `deadlineTimestamp` only.