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

[Bug] clawback bugs overview version 1.8.2 #15703

Closed
BrandtH22 opened this issue Jul 7, 2023 · 12 comments
Closed

[Bug] clawback bugs overview version 1.8.2 #15703

BrandtH22 opened this issue Jul 7, 2023 · 12 comments
Assignees
Labels
bug Something isn't working

Comments

@BrandtH22
Copy link
Contributor

BrandtH22 commented Jul 7, 2023

What happened?

(note - these bugs are not consistently occurring but are reproducible occasionally with enough attempts following the process outlined in the summary)

Summary: Alice sends xch to Bob with a 24 hour clawback. Alice attempts to use the clawback feature but is not provided the option and has an indicator that the clawback is in progress:
image
image

Alice realizes this is an error and “Deletes Unconfirmed Transactions” in the GUI. At first the pending clawback transaction is removed and becomes no longer visible in the GUI:
image

Alice realizes this is also an error and resyncs via the GUI under settings/advanced. This first removes the pending clawback transaction while syncing occurs then returns the pending clawback transaction but this time with the needed clawback option:
image

P.s. during this process, Bob sees the transaction being sent from his own address:
image

Bugs Overview

Bug 1: After a period of time the senders view incorrectly shows that the transaction is in Clawing back state

Bug 2: After clearing transactions there are two different results (second is the bug):

  • clawback is available again to be clawed back
  • clawback does not reappear in the list for clawing back

Bug 3: After resyncing there are three different results (2-4 are the bug):

  • clawback is available again to be clawed back
  • clawback does not reappear in the list for clawing back
  • clawback appears as a confirmed transaction being sent to the clawback contract address (have not been able to reproduce this on my test machine but have this currently occurring on a mainnet transaction)
  • clawback appears for sender as confirmed but shows as still in the clawback contract (Can be claimed in…) for receiver

Bug 4: Receiver sees transaction as being sent from their own receive address

note - this bug has also been reported by morebytes and nanobyt3 in discord
workaround - in all instances I was able to use the cli to claim back the funds as the receiver so long as I determined the correct coinID for which I needed to use an explorer.

Version

1.8.2

What platform are you using?

macOS

What ui mode are you using?

GUI

Relevant log output

No response

@BrandtH22 BrandtH22 added the bug Something isn't working label Jul 7, 2023
@paninaro
Copy link
Contributor

paninaro commented Jul 7, 2023

@BrandtH22 Are you using wallet-only mode, or are you running (and syncing against) your own full node?

@ytx1991
Copy link
Contributor

ytx1991 commented Jul 7, 2023

There are some known resync issues. Can you test this fix? #15496

@BrandtH22
Copy link
Contributor Author

@BrandtH22 Are you using wallet-only mode, or are you running (and syncing against) your own full node?

I am sorry for my delayed response and not including this information originally.
All of those tests were done from wallet mode

I am currently testing the fixes that ytx linked and appear to have been merged into main, will report my results here by EoD

@ytx1991
Copy link
Contributor

ytx1991 commented Jul 14, 2023

It is merged to the main now

@BrandtH22
Copy link
Contributor Author

BrandtH22 commented Jul 14, 2023

@ytx1991 and @paninaro -
Notes from the current fixes that were merged into main, testing was performed on a mac using the current main branch running wallet-only mode:

Summary -
Alice sent clawback to bob
Both saw the transaction properly initially
Both lost visibility to pending clawback transaction after deleted unconfirmed transactions in their respective clients
Receiver was able to regain visibility by nuking the db and syncing from scratch
Sender was not able to regain visibility after multiple resync methods (including full resync while connected to a local trusted full node)

BUG:

  • pending clawback transactions are not properly synced after unconfirmed transactions are deleted

Workarounds:

  • Sender cannot clawback the transaction via cli but receiver can claim via CLI or GUI
  • Receiver can regain visibility by nuking the db and syncing from scratch

Full Overview of process:

Sending the clawback
Alice sent the clawback transaction to Bob and immediately sees the "Claw Back This Transaction Option" (seems first bug is resolved).

Receiver viewing the clawback
At his time Bob correctly sees that the transaction will be autoclaimed after the clawback period (and when removing the auto feature this tag correctly updates to "Can be claimed in..." and the reverse works perfectly as well)

Sender reviewing the clawback (note - receivers experiences the same after deleting unconfirmed transactions)
Just to be thorough Alice deletes unconfirmed transactions, the initial sending to the clawback contract is still present as confirmed (as expected) and the pending clawback transaction is removed from the list (as expected). Alice waits 10 minutes but does not see the pending clawback transaction return (the completed transaction to the clawback wallet is still visible). Alice then force reloads the client to no avail (ensured client was fully synced and waited 10 more minutes).

Next Alice closes and reopens the client but the pending clawback transaction is still not visible after the client syncs.
Alice then uses the GUI to perform a full resync but after syncing does not see the pending clawback transaction.
Alice gives this another 10 minutes just to be sure the sync is occurring properly and reviews the client log file but there are no noticeable errors that would lead to it failing to sync the clawback coin.

Alice then "nukes" the db by:

  1. stopping the chia client
  2. deleting the wallet db for the fingerprint in use
  3. restarting the client
    Alice gives this time to sync and waits another 10 minutes but the clawback transaction is still not present.

NOTE - this is where the sender and receiver experience changes. Bob (the receiver) does again the pending clawback transaction after nuking the DB

Lastly, Alice syncs up a local trusted full node then again "nukes" the db. Unfortunately this did not provide visibility to the pending clawback transaction.

@BrandtH22
Copy link
Contributor Author

p.s. thank you for all of the attention on this :)

@zsolt-dev
Copy link

@BrandtH22 I am following this, but everything is backend related from my POV. On the FE I am just displaying whatever the backend returns to me. If you believe something is a FE issue, please let me know. Thank you

@wjblanke
Copy link
Contributor

please retest in 2.0.0-b5

@BrandtH22
Copy link
Contributor Author

please retest in 2.0.0-b5

Hey, just tested and the bug persists. It seems that the senders wallet is unable to find and/or interact with the pending clawback coin after the walletDB has been deleted.

Steps to reproduce:

  • Create a clawback coin
  • Close the chia client
  • Remove the wallet db
  • Restart the client

Representation of bug:

  • Sender is unable to see clawback this transaction in wallet
  • Senders transaction list updates to only show the coin outgoing to the clawback contract address
  • Sender is unable to se clawback transaction in cli commands (get_transaction with or without clawback flag)
  • Receiver has no issues deleting the wallet db and seeing the pending clawbacks after resync

@wjblanke
Copy link
Contributor

This is being worked on. Thanks for your report!

@ytx1991
Copy link
Contributor

ytx1991 commented Jul 26, 2023

The fix #15853 is verified

@BrandtH22
Copy link
Contributor Author

Confirmed that the fix has been verified in #15853

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants