Phantom order 👽 0x97ff915f6783fdba0ed03d8dc0b60f90186c08646ebbe0cd1e25863ee700478d

[chlenc]

Issue Title: Phantom Order - Order Closed on Contract but Open on Indexer

Description: We have identified an issue where an order appears as closed on the contract but remains open on the indexer. We refer to this kind of problem as a "phantom order."

Order ID: 0x97ff915f6783fdba0ed03d8dc0b60f90186c08646ebbe0cd1e25863ee700478d

Steps to Reproduce:

1. Verify Order Status on Contract: Using this script, we confirmed that the order is closed on the contract: Order Status Script

2. Verify Order Status on Indexer: Using the following GraphQL query, we confirmed that the order is still open on the indexer:

   query MyQuery {
    SpotOrder(
      where: {id: {_eq: "0x97ff915f6783fdba0ed03d8dc0b60f90186c08646ebbe0cd1e25863ee700478d"}}
    ) {
      timestamp
      order_type
      base_size
      base_price
    }

Our debug

In our contract, every order modification triggers an OrderChangeEvent. You can view the event definition here: OrderChangeEvent.

During debugging, we discovered that there were three OrderChangeEvent events emitted on the contract: create, match, and a final match that closed the order. However, the last match event is missing on the indexer.

To get the list of events on the contract, we used this script: Get Order Change Events by Order.

To fetch the list of events on the indexer, we used the following GraphQL query:

query MyQuery {
  SpotOrderChangeEvent(
    where: {order_id: {_eq: "0x97ff915f6783fdba0ed03d8dc0b60f90186c08646ebbe0cd1e25863ee700478d"}}
  ) {
    tx_id
    timestamp
    order_id
    identifier
    new_base_size
  }
}

Expected Behavior:

The order should be marked as closed on both the contract and the indexer.

Actual Behavior:

The order is closed on the contract but remains open on the indexer, creating a discrepancy.

Impact:

This issue leads to inconsistencies between the contract state and the indexer state, potentially causing confusion and incorrect data reporting.

Environment:

• Indexer: https://github.com/compolabs/spark-envio-indexer
• Contract: https://github.com/compolabs/orderbook-contract

[JasoonS]

The indexer receives all those events.

There is a logic bug in the handler.

When I run the indexer with this code:

OrderBookContract.OrderChangeEvent.handler(({ event, context }) => {
  if ("0x97ff915f6783fdba0ed03d8dc0b60f90186c08646ebbe0cd1e25863ee700478d" == event.data.order_id.toLowerCase()) {
    context.log.error(`OrderChangeEvent with id: ${event.data.order_id}. Changing transactionId to: ${event.transactionId}`);
  }

/// ... rest of  logic in handler
}

I get this output:

The indexer is getting the event - but the appropriate logic to handle that order isn't present in that handler.

[JasoonS]

Here is the commit I used to debug: https://github.com/compolabs/spark-envio-indexer/commit/47c0f8b3fd67e8abe43e47bc4d807c20e329f77b

[DZakh]

I've checked the transaction 0xe5f7cddcb82c0de90ec1967f041009fd8678afd8f5268e9398f2426e5323072a in the block explorer https://app.fuel.network/tx/0xe5f7cddcb82c0de90ec1967f041009fd8678afd8f5268e9398f2426e5323072a/simple, and there's only one LOG_DATA receipt. Please report the issue to the Fuel team so they can continue the investigation. Probably, it was broken, after they changed logId to the type hashes.