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

ZIP 320 manual testing ultimate Issues #1483

Closed
juanky201271 opened this issue Oct 30, 2024 · 7 comments
Closed

ZIP 320 manual testing ultimate Issues #1483

juanky201271 opened this issue Oct 30, 2024 · 7 comments
Assignees

Comments

@juanky201271
Copy link
Contributor

  1. I can see the refund transparent addresses in the Value Transfers List instead a send-to-self transaction without address.
  2. The transmitted transactions aren't persistent when you close/open the App. (Intermittent behavior).
  3. When the first transaction is confirmed I can see a transparent amount and I can shield it, if I do, the shield transaction is confirmed and the second transmitted transaction disappears.
  4. When the fist transaction is confirmed I can send funds to another address, if I do, the send transaction is confirmed and the second transmitted transaction stays in the history immutable for hours, and finally disappears.

@Edicksonjga Maybe you have more or another issues...

@zancas
Copy link
Member

zancas commented Oct 31, 2024

Really nice work!

I'd like to work out a road map where eventually all of these states are scripted in an emulator and asserted to be correct.

I think detox tests might permit that?

@Edicksonjga @juanky201271 @dorianvp

Can we meet to discuss the work that remains to get to that point for our test harness?

@zancas
Copy link
Member

zancas commented Oct 31, 2024

I see this as a cross-repo concern.

I believe we need to have automated tests running on an emulated app that verify the state of each of these flows. (In zingo-mobile?)

I believe that these issues should properly be fixed in zingolib.

@fluidvanadium
Copy link
Contributor

i am sure, based on edicksonz results, that 3 and 4 are due to #1437

@juanky201271
Copy link
Contributor Author

I see this as a cross-repo concern.

I believe we need to have automated tests running on an emulated app that verify the state of each of these flows. (In zingo-mobile?)

I believe that these issues should properly be fixed in zingolib.

I'm working on e2e test for those flows... in zingo-mobile.

@juanky201271
Copy link
Contributor Author

juanky201271 commented Nov 2, 2024

about the number 1 issue I noticed something interesting... 2 different scenarios:

  • If you update the App normally and you have your wallet there, when you send to TEX sometimes (maybe always...) you can see the refund address.
  • If you install the App and restore from seed OR if you run a Rescan with the new version of the App, when you send to TEX you always see the send-to-self transaction and you DO NOT see the refund addresses at all.

I hope this make sense to someone... @zancas @fluidvanadium @AloeareV

@juanky201271 juanky201271 self-assigned this Nov 2, 2024
@juanky201271
Copy link
Contributor Author

Update:

  1. Solved. I don't see this anymore.
  2. I keep see this in the lasts manual testings.
  3. & 4. I think these are not Bugs, just the normal behavior of creating two sequential transactions... obviously if the seconds one take a bit more time, the user can do actions with the App. I think these are hard to prevent.

@juanky201271
Copy link
Contributor Author

Update:
2. Solved. I don't see this anymore.

Closing...

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

No branches or pull requests

5 participants