hirosystems
Pruning Confirmed Tx's from Mempool - eg fix GET /extended/v1/tx/mempool?address={address}
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)
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.
@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)
Closing this as it may be fixed by the removal of microblocks. Please reopen if you see this resurface.
