What can clients do to best handle the API not showing mempool txs issue?

[kyranjamie]

Opening this to discuss what wallet clients can do to best handle the API issues described in https://github.com/hirosystems/devops/issues/797, where newly broadcast transactions don't appear in the mempool

cc/ @yknl, author of Xverse wallet

[markmhendrickson]

It seems like the key question here is whether we can improve nonce value setting on the client-side by tracking all recent transactions as submitted to the API on the client-side, in the scenario that the API doesn't return any information about these transactions at any point after submission.

I've been presuming with #1715 that this would be helpful, since the client could keep upping the nonce consistently with the combination of client-side data (for new transactions placed in "submitted" state per this discussion) and server-side data (for previous transactions). @aulneau appears to have the same idea with #1726.

Note that this would help only users of the same wallet installation, since obviously if they go to another one, the cached state there won't help with nonce calculations on the client-side. I presume, however, that most users affected by the API propagation issues are facing them only within the context of a single installation.

However, @yknl and @kyranjamie appear doubtful this will help and might even exacerbate issues with nonce setting. Perhaps we should spell out some particular scenarios in which this would get us in trouble?

[beguene]

#1715 will correctly increase the nonce based on local activity but the api will take precedence because the api endpoint we use to get the latest correct nonce WILL return a value but incorrect. The wallet does not know that this value is incorrect.

[beguene]

@markmhx Regarding the extra follower ref https://github.com/hirosystems/devops/issues/797#issuecomment-920311268
If I understood correctly I think some nodes (extra followers) which are not api production node are picking up the tx but the prod node does not know about it.

[markmhendrickson]

The wallet does not know that this value is incorrect.

Couldn't the wallet use its local nonce value if it has any submitted transactions that haven't been confirmed as pending or "better" by the API? That seems like a reliable heuristic to me that "API is having problems propagating, resort to backup mechanism", unless I'm missing something?

[fbwoolf]

Trying to catch up on all the discussion here, but I agree with @kyranjamie and @beguene on this. I believe trying to handle this client-side will likely create more issues for us.

[aulneau]

Couldn't the wallet use its local nonce value if it has any submitted transactions that haven't been confirmed as pending or "better" by the API? That seems like a reliable heuristic to me that "API is having problems propagating, resort to backup mechanism", unless I'm missing something?

This is my thinking too, and I believe it to be one that can work.

[kyranjamie]

While the API isn't working properly, we should to communicate to our users that the API is experiencing problems.

This could be achieved by implementing a wallet instability message, similarly to how is described in #1411

[andresgalante]

Big plus one for this, more than anything else clear communication is key at times of uncertainty.

[kyranjamie]

Could we get this spec'd out @markmhx @jasperjansz? We should consider there being different variants, more than 1 at a given time, link to external resource, maximum length, whether it's dismissible etc.

[fbwoolf]

Plus one for this too.