Cosmos-sdk: Same sequence from LCD after committing a block

[youngjoon-lee]

Summary of Bug

After a transaction is succeeded with the broadcast-mode block, I tried to get the new account sequence from LCD via /auth/accounts/{address}. But, it returned the old sequence (the one that I used for the transaction).
After sleeping for 1+ seconds, I could get the new sequence.
I'm curious why it takes some time even though I set the broadcast-mode block.

Interestingly, it never happens when I query the sequence via the Gaia CLI (instead of LCD). The CLI always returns the new sequence without any sleep.

I also posted this question to the Cosmos Forum: https://forum.cosmos.network/t/same-sequence-from-lcd-after-committing-a-block/4047.

Version

v0.35.0

Steps to Reproduce

# Check the sequence before executing the transaction (via both CLI and LCD)
gaiacli query account cosmos1eet7mg4v8u3lew8vwrtmwpptstn25ysj43q6a6
curl localhost:1317/auth/accounts/cosmos1eet7mg4v8u3lew8vwrtmwpptstn25ysj43q6a6

# Execute a transaction
gaiacli tx send cosmos1eet7mg4vptstn25ysj43q6a68u3lew8vwrtmwp 10000000uatom --chain-id testing --from validator

# Check the sequence after executing the transaction (via both CLI and LCD)
gaiacli query account cosmos1eet7mg4v8u3lew8vwrtmwpptstn25ysj43q6a6
curl localhost:1317/auth/accounts/cosmos1eet7mg4v8u3lew8vwrtmwpptstn25ysj43q6a6

# Then, only LCD returns the old sequence.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[alexanderbez]

The (legacy) REST API (not called LCD btw) is probably delayed somehow. When you don't explicitly provide a height query, it'll use the latest height. However, the latest height it queries could be the one before the tx was committed in.

[youngjoon-lee]

@alexanderbez Thank you for your reply.

I don't fully understand why the latest height that REST API queries could be the one before the tx was committed in. I might miss something when I read the cosmos source code.

I've made the Java SDK of my blockchain communicate with REST API.
But, from your comment, it seems that it's not recommended to use REST API anymore, because it might be not accurate to get the latest height for using it to make a next ...?height=x request.
Is REST API going to be deprecated? Then, what's your recommendation to implement my blockchain Java SDK.

[alexanderbez]

The legacy API is being deprecated in favor the gRPC HTTP Gateway API. Regardless, when providing an explicit height as part of the query, it should be taking the same execution path as the CLI more or less:

Essentially every route handler looks something like this:

        ctx, ok := rest.ParseQueryHeightOrReturnBadRequest(w, clientCtx, r)
        if !ok {
            return
        }

        // ...

        res, height, err := ctx.QueryWithData(route, bz)
        if rest.CheckInternalServerError(w, err) {
            return
        }

        ctx = ctx.WithHeight(height)
        rest.PostProcessResponse(w, ctx, res)

When you get the response from the API, what is the height in the response? The height the tx was committed at or one before?

[youngjoon-lee]

Because I'm using v0.35.0, the REST response doesn't contain the height (As I know, it was changed at v0.36.0).

Instead, I checked the latest height by both CLI and REST like below.
The Tx is done with the height 28492243, and both CLI and REST returned the latest height 28492243.
But, the CLI says the account sequence is 11011, but the REST says 11010.

Do you have any idea about this result? I'm also taking a look at the cosmos code.

+ panaceacli tx aol add-record ... -b block
...
Response:
  Height: 28492243
  TxHash: C1366C5AD92667F31981D1C627DD893F80FA30282B8C4DE5FC8835BD3B1EDCF4
  ....
  Raw Log: [{"msg_index":"0","success":true,"log":""}]
  ...


+ panaceacli status
{"node_info":{"protocol_version":{"p2p":"7","block":"10","app":"0"},"id":"22ef7df8f45ae6c31cfd65aade415549a3d96f98","listen_addr":"tcp://0.0.0.0:26656","network":"hygieia-1","version":"0.31.12","channels":"4020212223303800","moniker":"medibloc","other":{"tx_index":"on","rpc_address":"tcp://0.0.0.0:26657"}},"sync_info":{"latest_block_hash":"EAAFC84F0BF88AD0E32E4FAE8141AC8DDA2270A3A7724202BA88DE43BD2B72B0","latest_app_hash":"308C82D49974A92B841BEBC8DA1A59952885D262844552C0313160BC064B7C72","latest_block_height":"28492243","latest_block_time":"2020-10-16T01:25:39.670583474Z","catching_up":false},"validator_info":{"address":"D49D2E65144FAA21331FB24222AE9F7A7C7A5DF1","pub_key":{"type":"tendermint/PubKeyEd25519","value":"vEY7pPmrKDN/I1HHznQyUDvbKJzU45PuVjncnnwkZFA="},"voting_power":"0"}}


+ panaceacli query account panacea1d8xsncdn4m9e0gxx4u9jq3u84rd88tdkthz6pu
Account:
  Address:       panacea1d8xsncdn4m9e0gxx4u9jq3u84rd88tdkthz6pu
  Pubkey:        panaceapub1addwnpepqvsekjph8wmeulmwxg36fyurh2mjyt4q8j8kqckdaeqd8tntv4ml5vfe4zp
  Coins:         9904071799978umed
  AccountNumber: 3
  Sequence:      11011


+ curl localhost:1317/blocks/latest
{"block_meta":{"block_id":{"hash":"EAAFC84F0BF88AD0E32E4FAE8141AC8DDA2270A3A7724202BA88DE43BD2B72B0","parts":{"total":"1","hash":"8B987F51DA362DD94F7E22407EAD70133DA92EAFFE9EDFC234F37CA28F3B7AD9"}},"header":{"version":{"block":"10","app":"0"},"chain_id":"hygieia-1","height":"28492243","time":"2020-10-16T01:25:39.670583474Z","num_txs":"1","total_txs":"14846","last_block_id":{"hash":"30D328FC644C57F4A087BFEDD8A41C54F29D04DAE920FC6A487CF059EC863B0F","parts":{"total":"1","hash":"B528CE59DBA0B47EA82034711CAAB0E04C61E4B661232BA04CF123DF5BB45ED0"}},"last_commit_hash":"449C4BF2318BC69A3250E13CE1440AD74FA2E7E47FC812D52122F1D719787586","data_hash":"0771FD45D20EB74B8AD44E398398B1AF572E7CA4CB0DFCCF73064C289FF112F0","validators_hash":"36B24379F53B3FD4CCED65C4210886A78375B6EBF8E5ED37338ECB7E7FAD90D7","next_validators_hash":"36B24379F53B3FD4CCED65C4210886A78375B6EBF8E5ED37338ECB7E7FAD90D7","consensus_hash":"BAB5041D16246E2757DB17AF4B55FAAFBFD8660F7EB32871C99F91D0E58D5BF2","app_hash":"308C82D49974A92B841BEBC8DA1A59952885D262844552C0313160BC064B7C72","last_results_hash":"","evidence_hash":"","proposer_address":"CB4F77C3921844884662457BE01142D102DA8CDC"}},"block":{"header":{"version":{"block":"10","app":"0"},"chain_id":"hygieia-1","height":"28492243","time":"2020-10-16T01:25:39.670583474Z","num_txs":"1","total_txs":"14846","last_block_id":{"hash":"30D328FC644C57F4A087BFEDD8A41C54F29D04DAE920FC6A487CF059EC863B0F","parts":{"total":"1","hash":"B528CE59DBA0B47EA82034711CAAB0E04C61E4B661232BA04CF123DF5BB45ED0"}},"last_commit_hash":"449C4BF2318BC69A3250E13CE1440AD74FA2E7E47FC812D52122F1D719787586","data_hash":"0771FD45D20EB74B8AD44E398398B1AF572E7CA4CB0DFCCF73064C289FF112F0","validators_hash":"36B24379F53B3FD4CCED65C4210886A78375B6EBF8E5ED37338ECB7E7FAD90D7","next_validators_hash":"36B24379F53B3FD4CCED65C4210886A78375B6EBF8E5ED37338ECB7E7FAD90D7","consensus_hash":"BAB5041D16246E2757DB17AF4B55FAAFBFD8660F7EB32871C99F91D0E58D5BF2","app_hash":"308C82D49974A92B841BEBC8DA1A59952885D262844552C0313160BC064B7C72","last_results_hash":"","evidence_hash":"","proposer_address":"CB4F77C3921844884662457BE01142D102DA8CDC"},"data":{"txs":["ygHwYl3uCkHxZZkSCgJ5ahIEa2V5MRoFZGF0YTEiFGnNCeGzrsuXoMavCyBHh6jac622KhRpzQnhs67Ll6DGrwsgR4eo2nOtthIVCg8KBHVtZWQSBzEwMDAwMDAQwJoMGmoKJuta6YchAyGbSDc7t55/bjIjpJODurciLqA8j2Bize5A065rZXf6EkD1OWrkF8I4iQ8aDqvGzDfVeF8SxBtwO/+D0kjfIYQolGw9NI3M+7EtcZEM/dpgf2zXWp65Tp5/FIdWKFz74y50"]},"evidence":{"evidence":null},"last_commit":{"block_id":{"hash":"30D328FC644C57F4A087BFEDD8A41C54F29D04DAE920FC6A487CF059EC863B0F","parts":{"total":"1","hash":"B528CE59DBA0B47EA82034711CAAB0E04C61E4B661232BA04CF123DF5BB45ED0"}},"precommits":[{"type":2,"height":"28492242","round":"0","block_id":{"hash":"30D328FC644C57F4A087BFEDD8A41C54F29D04DAE920FC6A487CF059EC863B0F","parts":{"total":"1","hash":"B528CE59DBA0B47EA82034711CAAB0E04C61E4B661232BA04CF123DF5BB45ED0"}},"timestamp":"2020-10-16T01:25:39.670742401Z","validator_address":"0A0C605A22A5843552A271915833C54C8DE31DFE","validator_index":"0","signature":"JFQZ5xOwdoV/Ifvts11ZKN2NlNMpSDLi15GPE8MounmJ93FbIBpZTmZNsS//THIKXmwWEgfREzrB/u1iuUmDAg=="},{"type":2,"height":"28492242","round":"0","block_id":{"hash":"30D328FC644C57F4A087BFEDD8A41C54F29D04DAE920FC6A487CF059EC863B0F","parts":{"total":"1","hash":"B528CE59DBA0B47EA82034711CAAB0E04C61E4B661232BA04CF123DF5BB45ED0"}},"timestamp":"2020-10-16T01:25:39.670583474Z","validator_address":"0F8059E234869EB2EEAC7B3526DB643AA97B734F","validator_index":"1","signature":"jSX526WEBAV+6e0kMBSWvCDPatj+iQuQSkMzSWDFxPmFLisaQBOf2v4sDxxtYkndltAC7WrEe5l+sJwpsOgNBA=="},{"type":2,"height":"28492242","round":"0","block_id":{"hash":"30D328FC644C57F4A087BFEDD8A41C54F29D04DAE920FC6A487CF059EC863B0F","parts":{"total":"1","hash":"B528CE59DBA0B47EA82034711CAAB0E04C61E4B661232BA04CF123DF5BB45ED0"}},"timestamp":"2020-10-16T01:25:39.667843226Z","validator_address":"CB4F77C3921844884662457BE01142D102DA8CDC","validator_index":"2","signature":"veR7Liy7uNUhO/n3IaOsSO7tIwpcnWqgdU8pXXR5nf8m6Zs5bEb1H3ZRi7IlCd/s6iKE8Z8tzWs8MddMNegiAg=="}]}}}

+ curl localhost:1317/auth/accounts/panacea1d8xsncdn4m9e0gxx4u9jq3u84rd88tdkthz6pu
{"type":"auth/Account","value":{"address":"panacea1d8xsncdn4m9e0gxx4u9jq3u84rd88tdkthz6pu","coins":[{"denom":"umed","amount":"9904072799978"}],"public_key":{"type":"tendermint/PubKeySecp256k1","value":"AyGbSDc7t55/bjIjpJODurciLqA8j2Bize5A065rZXf6"},"account_number":"3","sequence":"11010"}}

[alexanderbez]

but in the snippet you provided, both the CLI and REST server are returning the same view of the account. No?

[youngjoon-lee]

The CLI returned the sequence 11011.

panaceacli query account panacea1d8xsncdn...
...
  Sequence: 11011

But, the REST server returned the sequence 11010.

curl localhost:1317/auth/accounts/panacea1d8xsncdn...

{"type":"auth/Account",....,"sequence":"11010"}}

[youngjoon-lee]

@alexanderbez

I just found that it works well on v0.37.14 (which is the latest release). Both CLI and REST returned the correct sequence which was increased by 1.
I also check that both CLI and REST took the same code path: queryAccount() in the x/auth/querier.go.

On v0.35.0, I found the code path is different.
When I used CLI, the cosmos server goes into the queryAccount().
But, when I used REST, the queryAccount() wasn't called. The REST handler in the QueryAccountRequestHandlerFn() is called in the REST server, and it calls the QueryStore().

I'm not sure how this difference affects on my issue, but it seems the issue was fixed somewhere between v0.35.0 ~ v0.37.14.
Could you confirm it?

[alexanderbez]

@youngjoon-lee can you use 0.39 or better yet, prepare for stargate? We don't support 0.35 anywmore.