hirosystems / stacks-blockchain-api

API for the Stacks blockchain
https://stacks-blockchain-api.vercel.app
GNU General Public License v3.0
172 stars 111 forks source link

Pruning Confirmed Tx's from Mempool - eg fix GET /extended/v1/tx/mempool?address={address} #1930

Closed cryptocracy closed 3 months ago

cryptocracy commented 5 months ago

Describe the bug During the process of trying to quality assure the pending claims of rewards in Derupt. this tx 0xfc644e2df312163cd584e5518a21a06a6fd859105022a5d60102b2834c6b820e is really confusing us.

Per hiro api response from https://api.mainnet.hiro.so/extended/v1/tx/mempool?address=SP1NNJSHTNQ551JNJB79YVNY16EW9AW50YF60AREW you'll seet it b820e tx as pending and seemingly still in mempool.

Per hiro explorer and look up address details of SP1NNJSHTNQ551JNJB79YVNY16EW9AW50YF60AREW you'll see it b820e tx as confirmed on confirmed tab, but also as pending on pending tab.

The wallet in question appears to be updated and indicative of being confirmed since its claimed 3 MIA blocks so far and the balance is 6876 reflecting correctly.

However the api results still show as pending and in mempool when the tx says it was in blocks: STX #145278 :: BTC #837781 per tx lookup directly.

To Reproduce Unclear, but it sounds like a regression in the API where sometimes a tx isn't pruned from the mempool (likely related to re-orgs)

Expected behavior Response from GET /extended/v1/tx/mempool?address={address} shouldn't yield inclusion of transactions that are confirmed.

Screenshot ( of API Response after tx was confirmed via direct tx lookup) image

Console log n/a

Desktop (please complete the following information): n/a

Smartphone (please complete the following information): n/a

Additional context This makes rendering the appropriate transactional status in front end ux, of a claim function call thats pending in mempool, pretty obnoxious to track in the interim.

zone117x commented 4 months ago

@cryptocracy have you seen this since happen since 2.5 have activated? I think it may have been related to microblock re-org handling, and microblocks are no longer produced (see https://github.com/stacks-network/stacks-core/issues/4479)

smcclellan commented 3 months ago

Closing this as it may be fixed by the removal of microblocks. Please reopen if you see this resurface.