Occasional null response at /r/sat recursive endpoint

[samedcildir]

When we call https://ordinals.com/r/sat/260621444322646/at/-1 endpoint repeatedly, it sometimes returns "id": null instead of "id": "031d60cebab0d0e96f15ac512dbe3953ff1586d8e86f2f35e22bac76519bf0dbi3".

Response headers shows Cf-Cache-Status: BYPASS so it seems like Cloudflare doesn't cache this endpoint so its not an issue on Cloudflare cache.

This endpoint is used by https://ordinals.com/inscription/56251487 this inscription.

[cryptoni9n]

I was able to reproduce this with the following script:

#!/bin/bash

URL="https://ordinals.com/r/sat/260621444322646/at/-1"

while true; do
    response=$(curl -s "$URL")
    echo "Response: $response"

    # Check if the id field is null
    if echo "$response" | jq -e '.id == null' >/dev/null; then
        echo "Reached null response. Stopping script."
        break
    fi

    sleep 1  # Add a delay to avoid overwhelming the server
done

responses:

Response: {"id":"031d60cebab0d0e96f15ac512dbe3953ff1586d8e86f2f35e22bac76519bf0dbi3"}
Response: {"id":"031d60cebab0d0e96f15ac512dbe3953ff1586d8e86f2f35e22bac76519bf0dbi3"}
Response: {"id":"031d60cebab0d0e96f15ac512dbe3953ff1586d8e86f2f35e22bac76519bf0dbi3"}
Response: {"id":"031d60cebab0d0e96f15ac512dbe3953ff1586d8e86f2f35e22bac76519bf0dbi3"}
Response: {"id":null}
Reached null response. Stopping script.

[brandonjamesmarshall]

Can confirm that my site which relies on this specific endpoint has lately been not rendering correctly: https://ordinals.com/preview/5f34b7b224a952c1f902a02119cdbd9823111380cba2293ae87cd9a902485288i0

[veryordinally]

See also #3758 - this occasionally seems to affect routes across the board, including inscriptions https://ordinals.com/inscription/[ID]. Haven't figured out a pattern yet.

[cryptoni9n]

See also #3758 - this occasionally seems to affect routes across the board, including inscriptions https://ordinals.com/inscription/[ID]. Haven't figured out a pattern yet.

I'll retest today. I have a feeling this and #3758 could have been due to #3767, which was recently corrected.

[cryptoni9n]

I tested again this morning and wasn't able to reproduce. Anyone else?

[brandonjamesmarshall]

Yeah seems to have been resolved based on Casey's reply #3767 (comment)_

[raphjaph]

Yeah this should be resolved. Our syncing test server was accidentally behind the load balancer.