target-neighborhood parse problem

[ldeffenb]

Context

2.0.0

Summary

I configured a new sepolia testnet node with the following in the bee.yaml file: target-neighborhood: 110111101111111111100001 But it fails to start with the following logs:

"time"="2024-04-04 20:37:53.698675" "level"="info" "logger"="node" "msg"="mining an overlay address for the fresh node to target the selected neighborhood" "target"="110111101111111120000000"
"time"="2024-04-04 20:37:53.698693" "level"="error" "logger"="node" "msg"="got error, shutting down..." "error"="mine overlay address: bad character in binary address"
"time"="2024-04-04 20:37:53.698781" "level"="error" "logger"="node" "msg"="failed to build bee node" "error"="mine overlay address: bad character in binary address"

Don't ask me where the 2 came from!

Expected behavior

I expected the node to be mined with an overlay starting with 0xdeffe1...

Actual behavior

Node fails to start with the error above.

Steps to reproduce

Copy my target-neighborhood: 110111101111111111100001 into a new node .YAML file and try to start it up.

Possible solution

None at this time, other than to fix the binary parser that seems to be busted.

[ldeffenb]

I tried adding 4 more zeros to the end giving: target-neighborhood: 1101111011111111111000010000 But that ended up mining into: "target"="1101111011111111100000000000" which is still not correct, even though it didn't fail a parse this time.

[acha-bill]

We use gopkg.in/yaml.v2to parse yaml. It treats 110111101111111111100001 as a float64 and then returns it in exponential notation 1.1011110111111112e+23. Then we cast it to a string which results in 110111101111111120000000

Test

var config map[string]interface{}
yaml.Unmarshal(file, &config)

for k, v := range config {
    fmt.Printf("%s: %s\n", k, v)
}

config.yaml

target-1: 110111101111111111100001
target-2: "110111101111111111100001"
target-3: 0x110111101111111111100001
target-4: 0b110111101111111111100001

Results

target-1: %!s(float64=1.1011110111111112e+23)
target-2: 110111101111111111100001
target-3: 0x110111101111111111100001
target-4: %!s(int=14614497)

Since target-neighborhood opt is supposed to be a string. The best solution here is to wrap the value in quotes to force the parser to treat it is a string.

[ldeffenb]

Since target-neighborhood opt is supposed to be a string. The best solution here is to wrap the value in quotes to force the parser to treat it is a string.

It'd be nice if the config parser did that automatically (quoting them if not quoted by the user) for items that it expects to be strings. Inference is just not a good thing when the result isn't what would be expected.

[acha-bill]

We use viper to parse the config and it works fine IMO. If you enter a series of numbers, it should correctly parse it as a number. Let the user quote the value if they want a string.