Confd panics when config specifies >1 etcd node

[rafecolton]

With both 0.3.0-beta1 and 0.3.0, I get the issue described below. What am I doing wrong?

This works

etcd_nodes = [ 
  "http://<node-1>:4001"
]

This, on the other hand...

etcd_nodes = [ 
  "http://<node-1>:4001",
  "http://<node-2>:4001",
  "http://<node-3>:4001"
]

...produces this:

root@f9ce598c2cf0:~# confd -onetime
panic: reflect: slice index out of range

goroutine 1 [running]:
runtime.panic(0x616a20, 0xc210036a90)
        /usr/local/go/src/pkg/runtime/panic.c:266 +0xb6
reflect.Value.Index(0x608a40, 0x9e1d88, 0x176, 0x1, 0xc2100368b0, ...)
        /usr/local/go/src/pkg/reflect/value.go:916 +0x223
github.com/BurntSushi/toml.unifySlice(0x6081c0, 0xc21000a6a0, 0x608a40, 0x9e1d88, 0x176, ...)
        /Users/kelseyhightower/go/src/github.com/BurntSushi/toml/decode.go:215 +0x26f
github.com/BurntSushi/toml.unify(0x6081c0, 0xc21000a6a0, 0x608a40, 0x9e1d88, 0x176, ...)
        /Users/kelseyhightower/go/src/github.com/BurntSushi/toml/decode.go:129 +0x7c1
github.com/BurntSushi/toml.unifyStruct(0x615160, 0xc21001dc90, 0x6c02c0, 0x9e1d40, 0x196, ...)
        /Users/kelseyhightower/go/src/github.com/BurntSushi/toml/decode.go:169 +0x2ed
github.com/BurntSushi/toml.unify(0x615160, 0xc21001dc90, 0x6c02c0, 0x9e1d40, 0x196, ...)
        /Users/kelseyhightower/go/src/github.com/BurntSushi/toml/decode.go:125 +0x84f
github.com/BurntSushi/toml.unifyStruct(0x615160, 0xc21001dc00, 0x680e00, 0x9e1d40, 0x196, ...)
        /Users/kelseyhightower/go/src/github.com/BurntSushi/toml/decode.go:169 +0x2ed
github.com/BurntSushi/toml.unify(0x615160, 0xc21001dc00, 0x680e00, 0x9e1d40, 0x196, ...)
        /Users/kelseyhightower/go/src/github.com/BurntSushi/toml/decode.go:125 +0x84f
github.com/BurntSushi/toml.Decode(0xc210060000, 0xa7, 0x601480, 0x9e1d40, 0xa7, ...)
        /Users/kelseyhightower/go/src/github.com/BurntSushi/toml/decode.go:69 +0x107
github.com/BurntSushi/toml.DecodeFile(0x702690, 0x15, 0x601480, 0x9e1d40, 0x15, ...)
        /Users/kelseyhightower/go/src/github.com/BurntSushi/toml/decode.go:79 +0x100
github.com/kelseyhightower/confd/config.LoadConfig(0x702690, 0x15, 0x1, 0x9ea7f3)
        /Users/kelseyhightower/go/src/github.com/kelseyhightower/confd/config/config.go:83 +0x344
main.main()
        /Users/kelseyhightower/go/src/github.com/kelseyhightower/confd/confd.go:41 +0xae

[kelseyhightower]

Hmm. I need to check that out.

[kelseyhightower]

@rafecolton Can you try this from master?

[rafecolton]

I'm still experiencing the same issue. I've been investigating a bit and have the following data points:

• It looks like the panic is occurring on this line.
• I have a different project that uses toml for config and includes a []string element. Using the same version of BurntSushi/toml, I am unable to get the same issue.
• When decoding the confd.toml, the decoder is able to successfully retrieve the 0th index from the slice - it fails on the 1st index datav.Index(1). This is especially odd.
• When the config for Bob (the aforementioned project) gets parsed, it enters this code block (i.e. rv.IsNil() returns true) whereas when confd.toml gets parsed, it does not. Removing the rv.IsNil() condition so that rv.Set(reflect.MakeSlice(rv.Type(), sliceLen, sliceLen)) gets executed results in a successful confd -onetime run.
• Before your commit 74ed2ac1772b34c1bffdc34d39f1db4d7fa8ed7c, both Bob and Confd were using the same outdated version of BurntSushi/toml - not really relevant, but amusing :smile:

Still not sure what the cause is, but I will continue to investigate...

[rafecolton]

Hooray! Found the problem.

It looks like the issue is somewhere in the toml.DecodeFile() function - I have submitted a pull request for Confd (https://github.com/kelseyhightower/confd/pull/61) that reads in the file manually first and then uses toml.Decode() to parse the raw bytes. This is the strategy I employ in Bob, mainly because the toml.Decode() method was the first one in the README :trollface:

I tested it in the same case as above and can confirm that it works.

I will submit a bug report to BurntSushi once I get to work today, but for new, a few more precious hours of sleep!

[dangra]

issue can be closed per #61 (?)