Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

address view does not show unconfirmed transactions #277

Closed
raedah opened this issue Nov 17, 2017 · 8 comments · Fixed by #489
Closed

address view does not show unconfirmed transactions #277

raedah opened this issue Nov 17, 2017 · 8 comments · Fixed by #489

Comments

@raedah
Copy link

raedah commented Nov 17, 2017

No description provided.

@papacarp
Copy link
Member

Some sleuthing guidance for this one:

  1. if an address has no transactions in it previously, then addressHistory fails and it falls back to RPC to display the transactions which includes unconfirmed transactions.

addrHist, balance, errH := exp.explorerSource.AddressHistory(
address, limitN, offsetAddrOuts, txnType)
// Fallback to RPC if DB query fails
if errH != nil {
log.Errorf("Unable to get address %s history: %v", address, errH)
addrData = exp.blockData.GetExplorerAddress(address, limitN, offsetAddrOuts)

Thus we are able to see unconfirmed transactions sometimes.
image

  1. if an address does have transactions in it previously, then AddressHistory succeeds, unconfirmed transactions are retrieved, but never merged into the resulting output.

addressOuts, numUnconfirmed, err := exp.blockData.UnconfirmedTxnsForAddress(address)

They are just left in a the var uctxn and ignored. The fix is to merge these into the addrData.Transactions list, and likely re-slice that list to adhere to the start/limit inputs.

This is my theory as I haven't noticed an unconfirmed transaction go through that has previous history in it to verify and my testnet is not up right now.

If this is not urgent then due to the rework happening on addresses table this should likely be fixed after we sort out the disposition of #427 by either @dmigwi or I. If urgent I can put a PR in for it based on existing architecture.

@chappjc
Copy link
Member

chappjc commented May 17, 2018

Yes, this is absolutely right. I had started a branch fixing these issues, but never finished up. https://github.com/chappjc/dcrdata/commits/addr-page-fixes

I must have stashed teh changes related to the above issues though.

@chappjc
Copy link
Member

chappjc commented May 17, 2018

Please feel free to pick this up of course. But do not wait on PR #427 . It's big and breaking, so we're not going to rush it through. Although it's getting closer.

@dmigwi
Copy link
Member

dmigwi commented May 17, 2018

Since the unconfirmed transactions are already available in the frontend and the only problem is when they are displayed why not add a link to the UNCONFIRMED metric value such that when the link is clicked the unconfirmed txs appear.

hyperlink

I suggest we add the link to the box in red. Whats your take on this @papacarp?

@chappjc
Copy link
Member

chappjc commented May 17, 2018

Correction: I meant do not wait on *PR #427 *

@raedah
Copy link
Author

raedah commented May 17, 2018

I would do it the way @papacarp suggested, "merge these into the addrData.Transactions list, and likely re-slice that list to adhere to the start/limit inputs." That way the information is inline and does not require additional user interaction to access.

@chappjc
Copy link
Member

chappjc commented May 17, 2018

I agree with @raedah

@papacarp
Copy link
Member

Ok. I will put in a PR for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants