Arya
Arya
> But maybe it also hangs in CI when there are only 2 virtual CPU cores available? That might be a timing issue. I don't think it's a timing issue...
`mempool_requests_for_transactions` test failed again (bug https://github.com/ZcashFoundation/zebra/issues/5384): > Message: internal error: entered unreachable code: `MempoolTransactionIds` requests should always respond `Ok(Vec)`, got Ok(Nil) https://github.com/ZcashFoundation/zebra/actions/runs/3231180904/jobs/5290771906#step:3:6780
> Or we could check which ones `zcashd` supports or requires. It looks like `zcashd` doesn't support or require submission abbreviations.
@teor2345 I'm not sure how the error values are being used, a generic error may be good enough. I added a `check_state_for_duplicate` method that looks at the queued/sent blocks for...
@teor2345 I think this should be coupled with #5487 so we can check `can_fork_chain_at` when submitted blocks are received and reject them in a timely manner when their parent blocks...
The checkpoint step took 4-5 hours to get to [1810k blocks](https://github.com/ZcashFoundation/zebra/actions/runs/3223410431/jobs/5291373001#step:6:812) (timed out after ~1817k). Adding just one extra step this time.
ssh failure in `logs-checkpoint`: > Timeout, server 34.123.232.71 not responding. > > .. > > ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255]. https://github.com/ZcashFoundation/zebra/actions/runs/3236318547/jobs/5302131447#step:6:777
> I also saw these sync warnings in the logs: > > > 2022-10-11T03:59:58.369043Z WARN {net="Main"}: zebrad::components::sync::progress: chain updates have stalled, state height has not increased for 30 minutes. Hint:...
> do we still need this PR? I believe we do, but I'll just quickly check the logs for the timeouts and perhaps replace `logs-1790k` with `logs-1800k`.
> is there a github issue that this is related to that I can link in? No, this was ad-hoc and trivial.