Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to fetch first block after catching up. #5352

Closed
winder opened this issue May 3, 2023 · 2 comments · Fixed by #5798
Closed

Unable to fetch first block after catching up. #5352

winder opened this issue May 3, 2023 · 2 comments · Fixed by #5798
Assignees
Labels
bug Something isn't working Team Lamprey

Comments

@winder
Copy link
Contributor

winder commented May 3, 2023

Subject of the issue

After a fast catchup, fetching the messagepack encoded first block from the API returns a 404.

Steps to reproduce

In this test, we use the conduit profile and a version of algod which causes followers to pause after a fast catchup. This makes the issue easier to reproduce.

  1. mkdir test_data
  2. algocfg profile set conduit -d "test_data"
  3. algocfg set -p EndpointAddress -v "0.0.0.0:8080" -d "test_data"
  4. cp /path/to/go-algorand/installer/genesis/betanet/genesis.json test_data/genesis.json
  5. goal node start -d "test_data"
  6. goal node catchup -d "test_data" 26000000#LLCDX3RAAYVU7T4ZIHBVEK4SJCIAHK4IIJLVI52SJGJIBYJHZ75Q
  7. wait for catchup watch goal node status -d "test_data"
  8. curl -H "Authorization: Bearer "$(cat test_data/algod.token) "http://127.0.0.1:8080/v2/blocks/26000000?format=msgpack"

Note: format=json works: curl -H "Authorization: Bearer "$(cat test_data/algod.token) "http://127.0.0.1:8080/v2/blocks/26000000?format=json"

Expected behaviour

The msgpack encoded block is returned.

Actual behaviour

An error: {"message":"failed to retrieve information from the ledger"}

@winder winder added bug Something isn't working Team Lamprey labels May 3, 2023
@tzaffi
Copy link
Contributor

tzaffi commented May 4, 2023

Reiterating that the next round works just fine.

@Eric-Warehime
Copy link
Contributor

I'm not sure that this is actually a bug. That being said, we can change the behavior if we want to.

The reason the json request works and the msgp does not is because the json request does not include the Cert. When the msgp request attempts to lookup and encode the cert it finds nothing and errors whereas the json does not attempt to fetch the cert.

If you were to run the same catchpoint and make a msgp and json request against any of the previous ~1000 rounds before the catchpoint round you'd find the same behaviour--msgp errors while json does not. This is because the catchpoint catchup service does not fetch certs as part of its catchup process.

The reason that round 26000001 works is because that round and all of the rounds up to MaxAcctLookback were fetched by the regular catchup service after catchpoint catchup completed. Regular catchup does fetch the certs along with the blocks.

So if we want to be able to serve certs from the catchpoint round or any of the previous rounds fetched during catchpoint catchup we would have to add cert fetching to the catchpoint catchup service--which is doable, but currently does not happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Team Lamprey
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants