sat_ranges is null when it shouldn't

[simongltr]

I use ord 0.10.0

My transaction has been made one hour ago but I still can't fetch the sat_ranges:

curl -X GET --header 'Accept: application/json' 'http://127.0.0.1:4001/output/beb9789fd486d63a748a3fc3f4eb5115c234d211e9037b06f738e83b27fd88c1:3'

{"value":40000,"script_pubkey":"OP_PUSHNUM_1 OP_PUSHBYTES_32 9ec5fd6758fb4e3cdb1a267ad469febc1e10e31f75f75362f23bf7882626f226","address":"bc1pnmzl6e6cld8rekc6yeadg607hs0ppcclwhm4xchj80mcsf3x7gnqztyrck","transaction":"beb9789fd486d63a748a3fc3f4eb5115c234d211e9037b06f738e83b27fd88c1","sat_ranges":null,"inscriptions":[],"runes":{}}

This transaction is confirmed, is it normal to observe a long delay before having access to the ranges ? It's a problem because I'm implementing a rare/exotic extraction feature in the Hordes and I would like this feature to be "real time" ...

It already happened in the past, it took 25 min to get a non null sat_ranges.

Thank you for the help,
Simon

[raphjaph]

Are you running ord with --index-sats?

[simongltr]

Yes, I use the following command:

SCREEN -dmSL ord-soft ord --data-dir /home/ubuntu/ord_data --enable-json-api --rpc-url http://127.0.0.1:8332 --index-sats server --http --http-port 4001 --address 0.0.0.0

[raphjaph]

What does curl -s -H "Accept: application/json" 'http://127.0.0.1:4001/status' return?

[simongltr]

I get this:

ssh ord curl -s -H "Accept: application/json" 'http://127.0.0.1:4001/status'
OK%

For your information the sat_ranges are now returned, but for each new tx I need to wait

[raphjaph]

Ah you're on v.0.10.0. In the newest release /status now also returns information about the index:

{
  "blessed_inscriptions": 53986650,
  "cursed_inscriptions": 472043,
  "chain": "mainnet",
  "height": 825047,
  "inscriptions": 54458693,
  "lost_sats": 2895502904,
  "minimum_rune_for_next_block": "AAAAAAAAAAAAA",
  "rune_index": false,
  "runes": 0,
  "sat_index": true,
  "started": "2024-01-09T19:11:04.564437274Z",
  "transaction_index": false,
  "unrecoverably_reorged": false,
  "uptime": {
    "secs": 5586,
    "nanos": 484529576
  }
}

There could be a short delay(25min seems way too long though) since if the output is in bitcoind and not yet the ord index, it will fall back to asking bitcoind for the output information. So it could be that the block/transaction was still being processed by ord when you made the request so it fell back to asking bitcoind, which obviously did not add the sat ranges. As you can see it also doesn't show any inscriptions (in case there was one in that output).

I have a PR open that adds a field to the JSON if the output is already in ord or not: #2971.

Looking a bit further into the future we want to make ord feel more "real-time" by adding mempool support. Don't know what the timeline on that is though.

[raphjaph]

We made the server a lot faster in the newest release by properly dispatching long synchronous calls to a thread pool. I can recommend upgrading.

[simongltr]

Thank you for the help, I will start by upgrading to the last version and see the result.

[simongltr]

I updated ord to version 0.15.0, now it take less than 30 seconds. I love your optimisations.

Thank you for the help, closing the issue.
Simon