nspcc-dev / nspcc-dev/neofs-node
SN bootstrap retries
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 38
- Forks
- 51
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 38
Description
Is your feature request related to a problem? Please describe.
I'm always frustrated when I am thinking about SN's bootstrap process. If something goes wrong and the Alphabet has not approved SN's netmap entrance, SN waits for the next epoch to try its luck one more time.
Describe the solution you'd like
A node knows NR's VUB and is able to check its candidate status via netmap contract call. If nothing pleasant has happened for the VUB blocks, it the time to try one more time OR at least to log some panic messages that it not gonna take part in the game.
Describe alternatives you've considered
Do nothing. Epoch sleep time is not that critical for now.
Additional context
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in cmd/neofs-node/netmap.go around the bootstrap handling at lines 175-190, then inspect the linked netmap contract candidate-status call and issue #830. Trace how the node uses the NR VUB and determine the retry or diagnostic behavior for an unapproved candidate. Done means failed bootstrap does not wait unnecessarily, or clearly reports that the node will not enter the netmap.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- blockchain, distributed-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100