[MDSAL-694] VerifyException thrown when resolving leafrefs with TAPI models Created: 13/Oct/21  Updated: 15/Oct/21  Resolved: 15/Oct/21

Status: Resolved
Project: mdsal
Component/s: Binding codegen
Affects Version/s: 8.0.0, 8.0.5
Fix Version/s: 8.0.6

Type: Bug Priority: Medium
Reporter: Javier Errea Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File error.txt    
Issue Links:
Relates
relates to MDSAL-696 Do not use DerivableSchemaNode Resolved
relates to YANGTOOLS-1066 SchemaPath identification of SchemaNo... Resolved

 Description   

Following the discussion from the ODL forum (https://lists.opendaylight.org/g/kernel-dev/topic/86257574#555)

When building the tapimodels module in transport-pce project, the following error occurs with the tapi-notification model:

Caused by: com.google.common.base.VerifyException: Conflict on org.opendaylight.yangtools.yang.model.ri.stmt.impl.eff.RegularLeafEffectiveStatement@7e58b0f6 between LeafGenerator{argument=(urn:onf:otcc:yang:tapi-notification?revision=2020-06-16)uuid, addedByUses} and LeafGenerator{argument=(urn:onf:otcc:yang:tapi-notification?revision=2020-06-16)uuid, addedByUses}
    at com.google.common.base.Verify.verify (Verify.java:443)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.indexLeafGenerators (GeneratorReactor.java:350)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.indexLeafGenerators (GeneratorReactor.java:352)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.indexLeafGenerators (GeneratorReactor.java:352)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.mapToGenerator (GeneratorReactor.java:328)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.lenientResolveLeafref (GeneratorReactor.java:321)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.resolveLeafref (GeneratorReactor.java:297)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.AbstractTypeObjectGenerator.bindTypeDefinition (AbstractTypeObjectGenerator.java:362)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.AbstractTypeAwareGenerator.bindTypeDefinition (AbstractTypeAwareGenerator.java:53)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.bindTypeDefinition (GeneratorReactor.java:399)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.bindTypeDefinition (GeneratorReactor.java:401)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.bindTypeDefinition (GeneratorReactor.java:401)
    at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.execute (GeneratorReactor.java:155)
    at org.opendaylight.mdsal.binding.generator.impl.DefaultBindingGenerator.generateFor (DefaultBindingGenerator.java:68)
    at org.opendaylight.mdsal.binding.generator.impl.DefaultBindingGenerator.generateTypes (DefaultBindingGenerator.java:38)
    at org.opendaylight.mdsal.binding.java.api.generator.JavaFileGenerator.generateFiles (JavaFileGenerator.java:74)
    at org.opendaylight.yangtools.yang2sources.plugin.FileGeneratorTask.execute (FileGeneratorTask.java:66)
    at org.opendaylight.yangtools.yang2sources.plugin.FileGeneratorTask.execute (FileGeneratorTask.java:40)
    at org.opendaylight.yangtools.yang2sources.plugin.GeneratorTask.execute (GeneratorTask.java:36)
    at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.generateSources (YangToSourcesProcessor.java:335)
    at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.conditionalExecute (YangToSourcesProcessor.java:214)
    at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesMojo.execute (YangToSourcesMojo.java:139)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)

As per the email thread, this happens with this set of models: https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.1/YANG

 Comments   
Comment by Robert Varga [ 13/Oct/21 ]

We are violating and explicit assumption in mapToGenerator(), which is that there each EffectiveStatement has at most one Generator attached to it. This assumption happens to work for all the models we have in our platform, but TAPI seems to have a structure, where this does not hold, probably due to SchemaPath being the same, or the inheritance hierarchy this happens in.

At any rate, this same problem is triggered with MD-SAL models if we try to bring yangtools-8.0.0-SNAPSHOT to the party, because it has been unshackled from SchemaPath (YANGTOOLS-1066) and hence it is frequently the case that an EffectiveStatement object is visible in more than one part of the statement tree.

In order to fix this, we need to eliminate indexLeafGenerators() and fix mapToGenerator() not only consider the resolved EffectiveStatement, but rather the complete state of the SchemaInferenceStack. This means taking a List<EffectiveStatement> and using that to navigate the Generator tree. This is easier said than done, as this navigation is not 1:1, and when looking up a Generator we need to consider not only the parent->child axis, but also the groupings and augments of an AbstractCompositeGenerator.

The patch attached to this issue is identifying the source of badness and outlines what needs to be done to resolve it.

Generated at Wed Feb 07 20:10:36 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.