Inconsistent result from /extended/v1/tx/ endpoint

[raag-bitwave]

Describe the bug
While trying to make API call to the following API endpoint (see "To reproduce" below) the fields "block_time" and "block_time_iso" are not consistent. Random re-runs of the same API call returns different values for these two fields.

"block_time": 1696525605, "block_time_iso": "2023-10-05T17:06:45.000Z",

vs

"block_time": 1722213506, "block_time_iso": "2024-07-29T00:38:26.000Z",

To Reproduce
Steps to reproduce the behavior:

1. curl -X GET https://api.mainnet.hiro.so/extended/v1/tx/0x07c78aefc1fc1594da8a118f043324e251a539848f50cb3282249fd2da708dbb
2. Run the cURL command a few times and the response changes for fields "block_time" and "block_time_iso"

Expected behavior
Expected re-run of same API endpoint to return same API response as before
"block_time": 1696525605, "block_time_iso": "2023-10-05T17:06:45.000Z",

Screenshots
Here's a screenshot of how I reproduced it.

Console log
Truncated response:
Expected:
"block_time": 1696525605, "block_time_iso": "2023-10-05T17:06:45.000Z",

Re-run:

"block_time": 1722213506, "block_time_iso": "2024-07-29T00:38:26.000Z",

Desktop (please complete the following information):

• OS: MacOS
• Browser: N/A
• Version 15.5

Smartphone (please complete the following information):

• Device: N/A
• OS: N/A
• Browser N/A
• Version N/A

Additional context
N/A

[rafaelcr]

Thanks for the report @raag-bitwave we were still caching some old incorrect responses from before we applied recent block time fixes. We've purged the cache and you should start seeing responses go back to normal soon.

[raag-bitwave]

Thanks @rafaelcr. Unfortunately it looks like i'm still getting inconsistent responses at random. Tried the same block's transactions using the same endpoint and it's randomly returning a future date of 2024-07-29 on block_time and block_time_iso.

Edit: Getting the same issue on /extended/v2/blocks/{block_height} endpoint as well...

[CharlieC3]

Hey @raag-bitwave, would you be able to tell us the value of the cf-cache-status header in the response of a request that returns an old cached result? This would tell us definitively whether Cloudflare is the culprit here or not.

[raag-bitwave]

Hey @CharlieC3 got this in response headers:
'CF-Cache-Status': 'REVALIDATED'

This time I got an incorrect response for same fields while using this endpoint instead of transactions
https://api.mainnet.hiro.so/extended/v2/blocks/123566

[CharlieC3]

Thanks, not sure where you're located but I'm wondering if Cloudflare had a partial failure to clear its cache when we purged it yesterday. I just purged it again. Please let me know if you're still seeing issues. If you are, it may suggest there's a local caching layer that's interfering somehow, as non of us have been able to replicate this on our end.

[raag-bitwave]

It seems to be better than before however I was able to replicate it using multiple locations on a VPN earlier as well.
Cloud be a Cloudflare issue but it's very random so hard to replicate. I replayed the curl command multiple times to reproduce the issue

[CharlieC3]

Yeah we followed your instructions to the word and weren't able to replicate it, however we did not try multiple locations via VPN. I know that Cloudflare will cache the response in multiple geographic regions around the world, so my guess is the purge did not propagate completely to certain regions. It's also possible your DNS cache is coming into play here and you're hitting some older Cloudflare servers which they recently removed/changed in DNS, but I can't be sure.

[raag-bitwave]

Yeah most likely. If it helps, the primary location intended for use is us-central1