Submodule including another submodule hits `Assertion `!inc->submodule' failed.` depending on order of main module includes.

[allena29]

I /think/ this is a libyang defect which has been found with Cisco XR 7.10.2 yang models from github - but there is a super small repro set of modules

Using devel (e736762) the following yang models fail due to - I think it was introduced in commit e736762 as part of #2390

libyang/src/tree_schema_common.c

Line 1256 in e736762

assert(!inc->submodule);

Smallest possible yang models to reproduce the issue

module b { 
// aka https://github.com/YangModels/yang/blob/main/vendor/cisco/xr/7102/tailf-common.yang

  namespace "urn:b";
  prefix "b";

  include d { // aka tailf-meta-extensions
    revision-date "2026-01-09";
  }
  include c { // aka tailf-cli-extensions
    revision-date "2026-01-09";
  }
  revision 2026-01-09 {
    description "example";
  }
}
submodule c {

  belongs-to b {
    prefix b;
  }
  include d { // aka tailf-meta-extensions
    revision-date "2026-01-09";
  }

  revision 2026-01-09 {
    description "example";
  }
}
submodule d {

  belongs-to b {
    prefix b;
  }

  revision 2026-01-09 {
    description "example";
  }
}

This is has been tested with a crude c program that (https://github.com/allena29/libyang/blob/tailf-meta-submodule-invalid/draft/yang_ls.c) that opens a context with LY_CTX_REF_IMPLEMENTED | LY_CTX_NO_YANGLIBRARY and loads the yang module b.yang

RFC Validity

My reading of the RFC is that it's is permitted for submoude c to include submodule d - both belonging to module b. However of course there can be interpretation applied.

Libyang behaviour

bad? behaviour

Depending on the include order in module b depends if we hit assert(!inc->submodule); or not

• module b includes submodule d and then submodule c - assert triggers

DEBUG: Parsing b.yang
libyang [2]: Searching for "d" in "/home/adam/libyang/draft/models". (line 0)
libyang [2]: Searching for "d" in "/home/adam/libyang/draft". (line 0)
libyang [2]: Loading schema from "/home/adam/libyang/draft/models/d.yang" file. (line 0)
libyang [2]: Searching for "c" in "/home/adam/libyang/draft/models". (line 0)
libyang [2]: Searching for "c" in "/home/adam/libyang/draft". (line 0)
libyang [2]: Loading schema from "/home/adam/libyang/draft/models/c.yang" file. (line 0)
libyang [2]: Searching for "d" in "/home/adam/libyang/draft/models". (line 0)
libyang [2]: Searching for "d" in "/home/adam/libyang/draft". (line 0)
libyang [2]: Loading schema from "/home/adam/libyang/draft/models/d.yang" file. (line 0)

Note: this is my attempt at some useful information rather than `tree_schema_common.c:1256: lysp_load_submodules: Assertion `!inc->submodule' failed.`

libyang [0]: Invalid YANG model structure: submodule "d" in module "b" is included multiple times or has a redundant dependency path. Check for redundant 'include' statements in sibling submodules. (line 0)
fish: Job 1, './yang_ls models' terminated by signal SIGABRT (Abort)

good behaviour

• module b includes submodule c and then submodule d - assert does not trigger

DEBUG: Parsing b.yang
libyang [2]: Searching for "c" in "/home/adam/libyang/draft/models2". (line 0)
libyang [2]: Searching for "c" in "/home/adam/libyang/draft". (line 0)
libyang [2]: Loading schema from "/home/adam/libyang/draft/models2/c.yang" file. (line 0)
libyang [2]: Searching for "d" in "/home/adam/libyang/draft/models2". (line 0)
libyang [2]: Searching for "d" in "/home/adam/libyang/draft". (line 0)
libyang [2]: Loading schema from "/home/adam/libyang/draft/models2/d.yang" file. (line 0)
SUCCESS: Loaded b

Question

What is the view from a libyang architecture point of view - is the structure of the yang models (i.e. submodule c including submodule d which belongs to the common parent) valid?

With the full Cisco models the following allows most of the models to be loaded into the context - however the presence of that assert would likely have good reason.

https://github.com/allena29/libyang/blob/tailf-meta-submodule-invalid/src/tree_schema_common.c#L1270-L1282

If it's not valid would a PR make sense to provide a more description of the error?

Thanks,
Adam