Not able to run check:construction

[rllola]

I am trying to run rosetta cli to check the construction endpoints. I have been able to run the check:data one.

I have the following message in loop:

2022/09/27 12:45:49 waiting for implementation to reach tip before testing...
[MEMORY] Heap: 3995.872131MB Stack: 0.531250MB System: 4233.206047MB GCs: 2
2022/09/27 12:45:59 {"code":0,"message":"unknown","description":"unknown error","retriable":false,"details":{"info":"post failed: Post \"http://127.0.0.1:26657\": read tcp 127.0.0.1:32862-\u003e127.0.0.1:26657: read: connection reset by peer"}}: retrying fetch for network status {"blockchain":"Cosmos","network":"theta"} after 0.602068s (prior attempts: 1)
2022/09/27 12:46:00 waiting for implementation to reach tip before testing...

I am not sure what is the issue with network status endpoint. It should be working correctly as I don't have issue when running check:data.

Here the command I used

./bin/rosetta-cli check:construction --configuration-file ./rosetta-config.json

And the rosetta-config.json

{
    "network": {
      "blockchain": "Cosmos",
      "network": "theta"
    },
    "online_url": "http://localhost:8080",
    "http_timeout": 120,
    "max_retries": 100000,
    "max_online_connections": 32,
    "max_sync_concurrency": 16,
    "tip_delay": 300,
    "log_configuration": false,
    "compression_disabled": true,
    "memory_limit_disabled": true,
    "construction": {
      "offline_url": "http://localhost:8080",
      "stale_depth": 3,
      "constructor_dsl_file": "cosmos.ros",
      "end_conditions": {
        "create_account": 10
      }
    },
...

[GeekArthur]

Looks like it's a connection issue as the remote server sent RST packet back to drop the connection from the TCP connection error message connection reset by peer, you can manually try /network/status (https://www.rosetta-api.org/docs/NetworkApi.html#networkstatus) to verify the response

check:construction periodically calls /network/status to check if it reaches to tip, but check:data also periodically calls /network/status for checking current status during validation, if the /network/status has some issues it should make both cases fail. One thing I notice is that in rosetta-config.json the online_url is http://localhost:8080, but the error message shows Post \"http://127.0.0.1:26657\, the port is different, not sure if that's the culprit

[rllola]

Calling /network/status works and also check:data seems to work for us too.

Here the curl answer :

$ curl -d '{"network_identifier": {"blockchain":"Cosmos","network":"cosmoshub-4"}, "metadata": {}}' -X POST "127.0.0.1:8080/network/status" -H  "accept: application/json"
{"current_block_identifier":{"index":12535767,"hash":"C94083BE0E116986C16F3712B39341F4E7E4DEACA6F731860D8BF0A49B4C8386"},"current_block_timestamp":1665210477090,"genesis_block_identifier":{"index":9283650,"hash":"0x09E5CC1760C63AB706C79D936024E35AE226D983724F3BB026C4BD1407CDB7FD"},"sync_status":{"current_index":12535767,"stage":"syncing"},"peers":[{"peer_id":"seed-01.theta-testnet.polypore.xyz","metadata":{"addr":"tcp://0.0.0.0:26656"}},{"peer_id":"seed-02.theta-testnet.polypore.xyz","metadata":{"addr":"tcp://0.0.0.0:26656"}},{"peer_id":"testing123blah","metadata":{"addr":"tcp://3.236.47.182:26656"}}]}

The port 26657 is a port used by Comsos so it could be that a internal call would fail... And because it failed it decided to wait and try again later... I am not sure.

[rllola]

I realize that my chain was far from being synced so I just increased the tip_delay.

[GeekArthur]

Yeah, probably the root cause is not the /network/status given the manual test works

Seeing waiting for implementation to reach tip before testing... means the chain is not at the tip and it's a blocker of triggering the transaction construction. I think increasing tip_delay can definitely speed up the the transaction broadcast process as the check:construction thinks the chain is at the tip even the chain is far from being synced, but it may still wait a pretty long time to pass the test as the test needs to confirm the new transaction is on the chain, which means the chain needs to keep syncing until detect the new transaction