Regression on the latest Zebra update

[Edicksonjga]

When using servers that use the latest Zebra update, the transactions in Zingo do not remain visible when they enter mempool, you must wait for the transaction to have a confirmation before you can see it in the history.

At ZingoLabs we were talking to Emerson and they confirmed that their servers are using version 2.2, while Hanh servers are using version 2.1, with Hanh servers this problem does not occur.

Do you have any idea what could be causing this problem?

Attached is a video of me performing a transaction in Zingo with ZEC-ROCK and with Zcash-Infra:

ZEC - ROCK

Transaction is Transmitted and on entering Mempool disappears, reappears when confirmed.

trim.1D5F3258-6D2E-416D-8FA1-133992549736.MOV

ZCASH - INFRA

Transaction is Transmitted, changes status when it enters Mempool, remains and changes to Sent when it is confirmed.

trim.26539C76-D2A4-4B63-B7B2-EF15887F64A7.MOV

I'm sure @Oscar-Pepper, @AloeareV or @zancas have more information about using sendrawtransaction and tracking in mempool.

[arya2]

Do you have any idea what could be causing this problem?

I expect it's related to Zebra's sendrawtransaction RPC returning success results as expected, and the migration to jsonrpsee looks like the only change between 2.1.0 and 2.2.0 that could affect that RPC, so I wonder if it works correctly with 1ecf655.

[zancas]

What's our protocol for testing this kind of issue?

Should we loop https://github.com/pacu in?

He might have the best overview of testing options for the community?

Is there an ask for deployment testing here?

I think that if we want e2e testing against deployed services, perhaps even some kind of A/B protocol then the best person to contact is e.g. https://github.com/emersonian.

I think we're entering a new phase of production where different classes of bugs should imply a standard approach, and a stakeholder.

Do we have a single master bug-tracker?

[mpguerra]

In order to help us identify the issue, @arya2 's requesting that this be reproduced with this commit: 1ecf655

We can then rule out or confirm what might be going on

[mpguerra]

What's our protocol for testing this kind of issue?

I guess it would depend on the impact. As far as I can tell there is no issue with loss of funds, it's just possible user confusion at seeing transactions disappear, as they do eventually re-appear and are processed correctly.

I think we're entering a new phase of production where different classes of bugs should imply a standard approach, and a stakeholder.

Is there anything that is currently not working with our current approach of triaging on github and assigning an engineer to investigate? I appreciate it took us a while to respond here, we were aware of this issue and it was discussed during the last Zcashd Deprecation meeting, however, the team was distracted with ZconVI last week.

Do we have a single master bug-tracker?

What would be the advantage of adding yet another place to check for issues? I think this would be a distraction to the team.

[mpguerra]

Is there an ask for deployment testing here?

I think that if we want e2e testing against deployed services, perhaps even some kind of A/B protocol then the best person to contact is e.g. https://github.com/emersonian.

I think this might be a good idea. I'm not sure where the responsibility lies here.

[pacu]

Can we single out Lightwalletd versions and also address Arya's comments?

[zancas]

Is there anything that is currently not working with our current approach of triaging on github and assigning an engineer to investigate?

Maybe a culture of direct contact? Ideally fewer people would need to pay attention to this issue.

[arya2]

This is currently being tested by Zingo