Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Phantom order 👽 0x97ff915f6783fdba0ed03d8dc0b60f90186c08646ebbe0cd1e25863ee700478d #7

Open
chlenc opened this issue Jun 9, 2024 · 3 comments

Comments

@chlenc
Copy link
Collaborator

chlenc commented Jun 9, 2024

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
    image

  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
      }

image

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.

image

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
  }
}

image

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:

@JasoonS
Copy link
Collaborator

JasoonS commented Jun 9, 2024

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:
image

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

@JasoonS
Copy link
Collaborator

JasoonS commented Jun 9, 2024

Here is the commit I used to debug: 47c0f8b

@DZakh
Copy link

DZakh commented Jun 10, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants