Incorrect interface for ExchangeRouter::updateOrder prevents order updates in GMX V2

GMX_Module::gmxv2_update is intended to call into GMX V2's ExchangeRouter::updateOrder to modify an open order. The module declares the call with the following five-parameter signature:

function gmxv2_update(
    bytes32 key,
    uint256 sizeDeltaUsd,
    uint256 acceptablePrice,
    uint256 triggerPrice,
    uint256 minOutputAmount
) external onlyRole(EXECUTOR_ROLE) nonReentrant {
    exchangeRouter.updateOrder(key, sizeDeltaUsd, acceptablePrice, triggerPrice, minOutputAmount);
}

The actual signature exposed by GMX's deployed ExchangeRouter::updateOrder includes two additional parameters:

function updateOrder(
    bytes32 key,
    uint256 sizeDeltaUsd,
    uint256 acceptablePrice,
    uint256 triggerPrice,
    uint256 minOutputAmount,
    uint256 validFromTime,
    bool autoCancel
) external payable nonReentrant { ... }

Because the function selector is computed from the argument types, the strategy is computing updateOrder(bytes32,uint256,uint256,uint256,uint256) while GMX exposes updateOrder(bytes32,uint256,uint256,uint256,uint256,uint256,bool). The selectors differ, so the call always reverts.

The audit included a Foundry PoC (test_gmxv2_update_SucceedGivenValidOrder) that creates a long, advances time, attempts an update, and shows the update reverts.

• The gmxv2_update function is non-functional and always reverts.
• Order updates (resizing, retriggering, adjusting acceptable price) are impossible.
• The trader's only workaround is to cancel and recreate the order, which costs an extra executionFee per cycle and introduces a window in which the position is exposed to the market.

Update the interface definition to include validFromTime and autoCancel, then propagate them through gmxv2_update. The trader should be able to pass these from off-chain calldata.

D2: Fixed in 23a48bc.

Cyfrin: Verified.