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

Chainlink node unable to start after backfill fails #847

Closed
boxhock opened this issue Dec 17, 2018 · 3 comments
Closed

Chainlink node unable to start after backfill fails #847

boxhock opened this issue Dec 17, 2018 · 3 comments

Comments

@boxhock
Copy link
Contributor

boxhock commented Dec 17, 2018

System Information

  • Commit (INFO line when starting the node): ce1acc5

Additional Information

If the Chainlink node attempts to backfill logs, but fails, it will be unable to properly start again.

Steps to recreate:

  1. Start a Chainlink node with a large backlog, which the ETH node will be unable to respond to. Optimally you would want the ETH node to be on cheap hardware too (larger chance of crashing), or straight up route the request through a reverse proxy that will imitate a failed request/error. Even just stop the ETH node while the CL node is getting the backlog?
  2. Expect following error: [ERROR] Unable to backfill logs services/subscription.go:346
  3. Restart CL node
  4. CL node will get ETH and LINK balances, but not process anything further. (No new headers being shown in console)

Every time it's restarted, it stops at balances. It definitely is receiving response for getLogs and getting new headers, but nothing is shown in the console.

Also: not sure if this is expected behavior, but when restarting the CL node, it's not attempting to backfill with the same block number that failed previously, but using the latest block number instead. Should it retry to backfill from the last successful block number?

@se3000
Copy link
Contributor

se3000 commented Jan 7, 2019

Thanks for reporting. Tracking this here: https://www.pivotaltracker.com/story/show/163037084

@se3000
Copy link
Contributor

se3000 commented Feb 23, 2019

@boxhock we were having trouble reproing this before version-0.6. I imagine it may have disappeared with that update. Can you still reproduce this?

@boxhock
Copy link
Contributor Author

boxhock commented Feb 28, 2019

@se3000 I did an effort to help John reproduce this issue, using the exact same steps as I followed when I initially encountered this issue, without any results. I'm going to assume the issue has been resolved with 0.6.

@boxhock boxhock closed this as completed Feb 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants