node: init blockchain state on startup

[carpawell]

Fixes #3066 on cold starts.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 18 lines in your changes missing coverage. Please review.

Project coverage is 22.36%. Comparing base (3a10bc1) to head (b0b1270).
Report is 5 commits behind head on master.

Files with missing lines	Patch %	Lines
cmd/neofs-node/netmap.go	0.00%	9 Missing ⚠️
cmd/neofs-node/config.go	0.00%	8 Missing ⚠️
cmd/neofs-node/reputation.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3069      +/-   ##
==========================================
- Coverage   22.36%   22.36%   -0.01%     
==========================================
  Files         793      793              
  Lines       58698    58713      +15     
==========================================
- Hits        13130    13129       -1     
- Misses      44667    44683      +16     
  Partials      901      901              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cthulhu-rider]

although proposed change is rly needed, it does not cover division by zero totally. Zero can still come from the service pov. I suggest:

1. preserve zero return in implementations
2. throw more clear panic in the service

we can also consider defaulting

[cthulhu-rider]

@carpawell #3066 (comment) what did u mean to fix?

[roman-khimov]

Epoch duration can't be 0. But this can be an operator error. In which case panic is not the best way to handle the problem. I'd suggest relying on proper value everywhere, but check it on update (including node start) and using the default if it's wrong.

Also, looks like t.objSharedMeta calculations can be omitted if !(t.localNodeInContainer && t.metainfoConsistencyAttr != "").

[cthulhu-rider]

neofs-node/pkg/network/transport/object/grpc/replication.go

Line 234 in 9019493

firstBlock := (uint64(currentBlock)/currentEpochDuration + 1) * currentEpochDuration

panics for the same reason

[carpawell]

@carpawell #3066 (comment) what did u mean to fix?

@cthulhu-rider, i meant do not encode meta info if it is not requested. It does not relate to panic directly so i would like to put this fix to another PR (like #3063 with some title change).

[carpawell]

Also, looks like t.objSharedMeta calculations can be omitted if !(t.localNodeInContainer && t.metainfoConsistencyAttr != "").

@roman-khimov, agree, will fix but IMO not in a fast panic fix PR.

[carpawell]

panics for the same reason

@cthulhu-rider, what do you mean? It shares the same netmap state that is updated right after creation after this PR.

[cthulhu-rider]

panics for the same reason

@cthulhu-rider, what do you mean? It shares the same netmap state that is updated right after creation after this PR.

just a remark, i faced this when hotfixed original panic with default to get working tests. Anyway, these are different places which can potentially panic

[cthulhu-rider]

node/nemtap:

and i still recommend to throw particular panic in places where the original one could occur

[roman-khimov]

It's all in neofs-node, likely you can have some nState.UpdateEpochDuration() that will handle this.

[carpawell]

ok, degraded logs a little then

[roman-khimov]

throw particular panic in places where the original one could occur

It's like adding dead code, not worth the trouble. This panic is rather obvious one even when the only thing you see is line number and "division by zero".

[cthulhu-rider]

dont forget about linter

[carpawell]

It's like adding dead code

Same opinion, zero division is a funny cult mistake, in go IMO not needed any context, devs will always understand what it is about, admins can do nothing about it