Bug that happens when having the same container name in .cli file and yang file

[shmuelnatan]

If one has a .cli file with the following definition

set {
         @datamodel, cli_merge();
         foo{
               boo<boo:string>, function_cb();
         }
}

And in the yang file, he has the following module

module FOO {
  container foo{
    leaf foo1{
         type string;
    }
}

Then if foo1 is not saved with a value in the startup db before booting the cli, then one can't set foo1. The following is an example.

cli> set foo foo1 soo
cli> commit
cli> show foo 
foo {
}

But if foo1 is set in the startup db then one can change it. For example, if foo1 has the value of soo in the startup db then one can do the following

cli> set foo foo1 soo1
cli> commit
cli> show foo 
foo {
    foo1 soo1;
}

I think that this is a bug that is caused by cligen that it doesn't know how to deal with two definitions that are mentioned in the .cli file and the yang file. I also know that this behavior did not happen in the 5.2 version.

[olofhagsand]

I see the same text in #301?

[olofhagsand]

I cannot recreate. Maybe this was fixed by some recent bugfixes which means it may work in HEAD, or there is something in your clixon config file that is different?
I made your example with the following result:

olof@alarik> clixon_cli -f /var/tmp/./test_309.sh/conf_yang.xml
olof@alarik /> set ContainerB ListA boo value boo
olof@alarik /> show configuration 
ContainerB {
    ListA {
        name boo;
        value boo;
    }
}

I append the complete example test below.
Please compare your test with that file and/or provide your:

1. clixon xml config file
2. debug logs of cli and backend

#!/usr/bin/env bash

# Magic line must be first in script (see README.md)
s="$_" ; . ./lib.sh || if [ "$s" = $0 ]; then exit 0; else return 0; fi

APPNAME=example

cfg=$dir/conf_yang.xml
fyang1=$dir/A.yang 
fyang2=$dir/B.yang 

# Generate autocli for these modules
AUTOCLI=$(autocli_config B kw-nokey false)

cat <<EOF > $cfg
<clixon-config xmlns="http://clicon.org/config">
  <CLICON_CONFIGFILE>$cfg</CLICON_CONFIGFILE>
  <CLICON_FEATURE>a:test</CLICON_FEATURE>
  <CLICON_YANG_DIR>$dir</CLICON_YANG_DIR>
  <CLICON_YANG_DIR>${YANG_INSTALLDIR}</CLICON_YANG_DIR>
  <CLICON_YANG_MAIN_FILE>$fyang2</CLICON_YANG_MAIN_FILE>
  <CLICON_CLISPEC_DIR>/usr/local/lib/$APPNAME/clispec</CLICON_CLISPEC_DIR>
  <CLICON_CLI_DIR>/usr/local/lib/$APPNAME/cli</CLICON_CLI_DIR>
  <CLICON_CLI_MODE>$APPNAME</CLICON_CLI_MODE>
  <CLICON_SOCK>/usr/local/var/$APPNAME/$APPNAME.sock</CLICON_SOCK>
  <CLICON_BACKEND_PIDFILE>/usr/local/var/$APPNAME/$APPNAME.pidfile</CLICON_BACKEND_PIDFILE>
  <CLICON_BACKEND_DIR>/usr/local/lib/$APPNAME/backend</CLICON_BACKEND_DIR>
  <CLICON_XMLDB_DIR>/usr/local/var/$APPNAME</CLICON_XMLDB_DIR>
  <CLICON_MODULE_LIBRARY_RFC7895>false</CLICON_MODULE_LIBRARY_RFC7895>
  ${AUTOCLI}
</clixon-config>
EOF

# This is the lib function with the base container
cat <<EOF > $fyang1
module A {
  namespace "http://A";
  prefix "MA";
  grouping GroupA {
      list ListA{
        key name;
        leaf name{
          type string;
        }
        leaf value{
          type string;
        }
     }
  }
}
EOF

cat <<EOF > $fyang2
module B {
  namespace "http://B";
  prefix "MB";
  import A {
    prefix "MA";
  }
  container ContainerB{
    uses MA:GroupA;
  }
}
EOF

new "test params: -f $cfg"
if [ $BE -ne 0 ]; then
    new "kill old backend"
    sudo clixon_backend -zf $cfg
    if [ $? -ne 0 ]; then
	err
    fi
    new "start backend -s init -f $cfg"
    start_backend -s init -f $cfg
fi

new "waiting"
wait_backend

[shmuelnatan]

After long research, I managed to pinpoint the issue that I saw on our devices. I changed the description and the name of the bug accordingly.

[olofhagsand]

This is because @ acts as a macro and expands all top-level symbols in @datamodel.
"foo" is such a top-level symbol and it gets in a conflict with the foo already in the manual syntax.
Is this an actual problem for you? otherwise I would recommend making a work-around.
I think a proper solution to this could be related to #253 , ie the usage of namespace prefixes for equal top-level symbols.
In this case, the module foo would have a prefix that could be used to make it unique.

[shmuelnatan]

This is because @ acts as a macro and expands all top-level symbols in @datamodel. "foo" is such a top-level symbol and it gets in a conflict with the foo already in the manual syntax. Is this an actual problem for you? otherwise I would recommend making a work-around. I think a proper solution to this could be related to #253 , ie the usage of namespace prefixes for equal top-level symbols. In this case, the module foo would have a prefix that could be used to make it unique.

This is a major issue for us since we relied on the previous behavior that we had in the 5.2 version.

[olofhagsand]

I think that was the same behavior before. Are you sure that this has changed?

[shmuelnatan]

I think that was the same behavior before. Are you sure that this has changed?

Yes. We had a .cli file with the same container name as in a yang file, and it worked fine in version 5.2. When we moved to 5.5 it stopped working.

[olofhagsand]

OK, will have a look on what has changed from 5.2

[olofhagsand]

Fixed by patch above.
@shmuelnatan, Can you please verify it?