The TL;DR version is that the format where nested keys are references (for overwriting in this case) in one key with dots instead of a nested mapping, isn't being "broken down" correctly in some cases.
What's interesting is to see that there are TWO composite keys insimple_grpc_service.yaml, runner.grpc and then implementation.class_name and while the latter, resolves correctly into a nested implementation and class_name, the former remains a single key runner.grpc and thus the intended overwriting of class_name under runner / grpc / implementation does not happen.
The TL;DR version is that the format where nested keys are references (for overwriting in this case) in one key with dots instead of a nested mapping, isn't being "broken down" correctly in some cases.
The example here goes something like this:
First we have defaults.yaml:
Then simple_grpc_service.yaml:
And this should result in:
But instead this happens:
What's interesting is to see that there are TWO composite keys insimple_grpc_service.yaml,
runner.grpc
and thenimplementation.class_name
and while the latter, resolves correctly into a nestedimplementation
andclass_name
, the former remains a single keyrunner.grpc
and thus the intended overwriting ofclass_name
underrunner
/grpc
/implementation
does not happen.