Closed cryptocracy closed 3 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)
Closing this as it may be fixed by the removal of microblocks. Please reopen if you see this resurface.
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 itb820e
tx as pending and seemingly still in mempool.Per hiro explorer and look up address details of
SP1NNJSHTNQ551JNJB79YVNY16EW9AW50YF60AREW
you'll see itb820e
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.