API returns non-mainnet block

[alecalve]

According to Tronscan and to our non-Rosetta node, block's 22286072 hash is:

0000000001540ef87b660ed664ed174e4f68f492e13810d9491d2c2a7f4a32c3

Yet, our Rosetta node returns the following data for height 22286072:

$ rosetta-cli view:block 22286072
{
 "block_identifier": {
  "index": 22286072,
  "hash": "0000000001540ef8b04d4a6c893a0a775b4415ccd9ffd5a5eb821e2c69850c7f"
 },
 "parent_block_identifier": {
  "index": 22286071,
  "hash": "0000000001540ef7a6f1a299e35febef634d6a9e965ad7449864ac30a4899096"
 },
 "timestamp": 1597129344000,
 "transactions": [
  {
   "transaction_identifier": {
    "hash": "0d049b10c0d9de2935eac5dbc0157fc0bab2a965209b0a31c6c655f2f212637d"
   },
...

The first transaction of that block was included in mainnet block 22286074 according to Tronscan.

Could it be that we are synchronizing a wrong branch of the network? Or could it be some issue with the rosetta implementation?

[alecalve]

Another related issue is that queries to /block that specify a hash returns data for a non-matching hash.

We send this query to the rosetta API, specifying which hash we want data for:

{
	"network_identifier": {
		"blockchain": "tron",
		"network": "mainnet"
	},
	"block_identifier": {
		"index": 22286072,
		"hash": "0000000001540efa135b1d67ac606c68579a39275099330962be3d8064640270"
	}
}

but we get back data for a block whose hash doesn't match:

{
	"block": {
		"block_identifier": {
			"index": 22286072,
			"hash": "0000000001540ef87b660ed664ed174e4f68f492e13810d9491d2c2a7f4a32c3"
		}
	}
}

[Yrp]

$ rosetta-cli view:block 22286072
{
 "block_identifier": {
  "index": 22286072,
  "hash": "0000000001540ef8b04d4a6c893a0a775b4415ccd9ffd5a5eb821e2c69850c7f"
 },
 "parent_block_identifier": {
  "index": 22286071,
  "hash": "0000000001540ef7a6f1a299e35febef634d6a9e965ad7449864ac30a4899096"
 },
 "timestamp": 1597129344000,
 "transactions": [
  {
   "transaction_identifier": {
    "hash": "0d049b10c0d9de2935eac5dbc0157fc0bab2a965209b0a31c6c655f2f212637d"
   },
...

Looks like it's on a forked chain.

[Yrp]

Another related issue is that queries to /block that specify a hash returns data for a non-matching hash.

The query order of the keys is

1. block number
2. block hash

The program assumes that the user has passed the correct mapping of block number to block hash.

[Yrp]

The issue will be closed and can be reopened if needed.