Lunie: Identify and avoid connecting to non-indexing nodes

[faboweb]

UI Version: 0.7.1

Description:

Usually nodes are not indexing transactions. This results in falsely txs not showing.

Tendermint shows us if a node is indexing via the status endpoint and the property node_info.other.tx_index

[jbibla]

is it unreasonable to propose that voyager won't connect to a non-indexing node without the user saying this is ok?

1. voyager tries to connect to an indexing node
2. if no indexing nodes found, full screen modal telling user that voyager can't find any indexing nodes, asking if voyager should try connecting to non indexing nodes
3. features effected by non-indexing nodes (like tx history) should have special error message stating that the node voyager is connected to is "non-indexing" with a button to try to find (or run locally?) an indexing node.

what do you think?

[faboweb]

Totally what I was thinking. Two 👍 from me.

[faboweb]

• let's try to push for indexing being mandatory

[jbibla]

also show correct message

[NodeGuy]

I requested that indexing be made mandatory and the SDK team said "no".

Other than the transaction history, which Voyager features are affected by a non-indexing node?

Another idea: How about Voyager doesn't connect to non-indexing nodes, period. We can handle more cases after launch.

[faboweb]

I guess most staking information. Am I wrong @fedekunze ?
I like the idea to skip non-indexing nodes. We just need to make sure, we have at least one per testnet. This should be possible, as we can make the testnet team do it. :)

[fedekunze]

• @faboweb @NodeGuy I like the idea of skipping non-indexing nodes, since we won't be able to query txs by tag. That affects mostly all actions (_i.e_ governance, staking, transfers, etc) and important queries we need in order for Voyager to work smoothly

[fedekunze]

@faboweb @NodeGuy should we also open an issue for more docs of what Node indexing is and what are the pros/cons of it ?

[faboweb]

yes @fedekunze please open one

[fedekunze]

See cosmos/cosmos-sdk#2132

[NodeGuy]

OK, I'll make Voyager skip non-indexing nodes.

[faboweb]

The mentioned status node_info.other.tx_index doesn't show actual indexing.

Example:
103.72.145.36:26657 shows tx-index=on but doesn't show txs.
195.201.141.141:26657, 51.38.113.60:26657 shows tx-index=on and shows txs.

Pulling in SDK team @cwgoes
Pulling in Tendermint team @xla

[NodeGuy]

Please submit a bug report in the SDK repo.

[fedekunze]

See cosmos/cosmos-sdk#2183

[cwgoes]

I believe this is a Tendermint RPC endpoint which the SDK doesn't handle.

[faboweb]

Isn't indexing handled by Tendermint?

[NodeGuy]

Sounds like the bug should be filed in the Tendermint repo.

[faboweb]

Created an issue on the Tendermint repo: https://github.com/tendermint/tendermint/issues/2304

[fedekunze]

We shouldn't be blocked on Voyager side. Even in the case there's an issue on the SDK or Tendermint, we still need to identify non indexing nodes. Therefore I'm removing the blocked label

[faboweb]

The problem is: We can't identify those nodes yet. There is no proposal for how to solve this yet.

[fedekunze]

Implementation ready, but blocked on not being able to test the results

[NodeGuy]

Is this now irrelevant because of https://github.com/cosmos/voyager/issues/1291?

[faboweb]

Is this now irrelevant because of #1291?

We can ice this PR. We can get back to it after launch.

[cwgoes]

I think we should keep trying to fix this - Voyager isn't the only client that might need to query indexing status, and we want the user to have the ability to select a different full node.

I'll try to take a look today or tomorrow.

[NodeGuy]

Iced.