viper.Sub() not extracting nested default values

[edermi]

I noticed an issue where viper.Sub() fails to extract default values of a nested key. I attached demo code to reproduce the issue using latest viper and Go 1.12.6 under x64_linux.

main.go:

package main

import (
	"fmt"

	"github.com/davecgh/go-spew/spew"
	"github.com/spf13/viper"
)

func main() {
	viper.SetDefault("config.value2.internal", 3)
	viper.SetConfigFile("./demo.yaml")
	err := viper.ReadInConfig()
	if err != nil {
		panic(fmt.Errorf("Fatal error config file: %s ", err))
	}
	// Until now, everything works as expected
	fmt.Printf("config.value1: %d\n", viper.GetInt("config.value1"))
	fmt.Printf("config.value2: %d\n", viper.GetInt("config.value2"))
	fmt.Printf("config.value2.internal: %d\n", viper.GetInt("config.value2.internal"))

	// Extract the config subtree
	v := viper.Sub("config")
	// This doesn't work if value2 node is missing in configuration
	fmt.Printf("value2.internal: %d\n", v.GetInt("value2.internal"))

	spew.Dump(v.AllSettings())
}

demo.yaml (works as inteded, but defaults are useless since everything is explicitly set):

config:
  value1: 1
  value2: 
    internal: 3

demo.yaml (broken):

config:
  value1: 1
  #value2: 
  #  internal: 3

Output for the broken example:

config.value1: 1
config.value2: 0
config.value2.internal: 3
value2.internal: 0
(map[string]interface {}) (len=1) {
 (string) (len=6) "value1": (int) 1
}

Whereas I would expect to have value2.internal: 3

The issue seems somehow related / similar to issue #71 as well as PR #195

[aquincum]

pretty impressive this hasn't been fixed in 3 years and it seems like it doesn't impact many...

[setrofim]

I ran into related issue when Get()'ing a sub-tree that defaults specified for some of its keys. The issue is that when a value is specified for a path in the config, it effectively shadows the corresponding path in the defaults. But if the nested deeper path is not present in the set value, path resolution falls back to looking in the defaults. This results in potentially inconsistent behaviour when accessing a configuration point via its full path results in one value (the default), while accessing it via a relative path from a sub-tree results an that type's null value (nil, 0, "", etc).

Potential fix in #1439

(note: this technically changes existing expected behaviour -- see the updated overrides_test.go; however, given this issue, and the referenced previous discussions, merging nested keys from defaults seems like desirable behaviour?)