[YANGTOOLS-1276] MandatoryLeafEnforcer fails when faced with augmentations Created: 21/Apr/21  Updated: 02/Nov/21  Resolved: 02/Nov/21

Status: Resolved
Project: yangtools
Component/s: parser
Affects Version/s: 6.0.6, 7.0.1, 5.0.10
Fix Version/s: 8.0.0

Type: Bug Priority: Medium
Reporter: Tibor Král Assignee: Tibor Král
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to YANGTOOLS-568 Remove AugmentationIdentifier and Aug... Resolved

 Description   

In case a mandatory leaf was added to node via augmentation, the MandatoryLeafEnforcer fails to find it. It is aware of the existance of the mandatory leaf, but only searches through the direct children of the node. This leads to "missing mandatory descendant" exception, as shown below:

java.lang.IllegalArgumentException: Node (http://org/openroadm/service?revision=2020-05-29)resource is missing mandatory descendant /(http://org/openroadm/service?revision=2020-05-29)type
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:441) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.MandatoryLeafEnforcer.enforceOnData(MandatoryLeafEnforcer.java:57) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.CaseEnforcer$EnforcingMandatory.enforceOnTreeNode(CaseEnforcer.java:43) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.ChoiceModificationStrategy.enforceCases(ChoiceModificationStrategy.java:130) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.ChoiceModificationStrategy.optionalVerifyValueChildren(ChoiceModificationStrategy.java:102) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.verifyValueChildren(AbstractNodeContainerModificationStrategy.java:126) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.fullVerifyStructure(SchemaAwareApplyOperation.java:153) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.verifyValueChildren(AbstractNodeContainerModificationStrategy.java:118) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.fullVerifyStructure(SchemaAwareApplyOperation.java:153) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.verifyValueChildren(AbstractNodeContainerModificationStrategy.java:118) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.fullVerifyStructure(SchemaAwareApplyOperation.java:153) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.verifyValueChildren(AbstractNodeContainerModificationStrategy.java:118) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.fullVerifyStructure(SchemaAwareApplyOperation.java:153) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.verifyValueChildren(AbstractNodeContainerModificationStrategy.java:118) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.fullVerifyStructure(SchemaAwareApplyOperation.java:153) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.ModifiedNode.seal(ModifiedNode.java:288) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractReadyIterator.process(AbstractReadyIterator.java:47) ~[?:?]
at org.opendaylight.yangtools.yang.data.impl.schema.tree.InMemoryDataTreeModification.ready(InMemoryDataTreeModification.java:298) ~[?:?]
at org.opendaylight.mdsal.dom.spi.store.SnapshotBackedWriteTransaction.ready(SnapshotBackedWriteTransaction.java:151) ~[?:?]
at org.opendaylight.controller.cluster.datastore.LocalTransactionFactoryImpl.onTransactionReady(LocalTransactionFactoryImpl.java:86) ~[?:?]
at org.opendaylight.controller.cluster.datastore.LocalTransactionContext.ready(LocalTransactionContext.java:100) ~[?:?]
at org.opendaylight.controller.cluster.datastore.LocalTransactionContext.directCommit(LocalTransactionContext.java:112) ~[?:?]
at org.opendaylight.controller.cluster.datastore.TransactionProxy.getDirectCommitFuture(TransactionProxy.java:334) ~[?:?]
at org.opendaylight.controller.cluster.datastore.TransactionProxy.createSingleCommitCohort(TransactionProxy.java:321) ~[?:?]
at org.opendaylight.controller.cluster.datastore.TransactionProxy.ready(TransactionProxy.java:286) ~[?:?]
at org.opendaylight.controller.cluster.datastore.TransactionProxy.ready(TransactionProxy.java:61) ~[?:?]
at org.opendaylight.controller.cluster.databroker.AbstractDOMBrokerWriteTransaction.commit(AbstractDOMBrokerWriteTransaction.java:140) ~[?:?]
at org.opendaylight.mdsal.binding.dom.adapter.BindingDOMWriteTransactionAdapter.commit(BindingDOMWriteTransactionAdapter.java:70) ~[?:?]
at com.fujitsu.fnc.sdnfw.odlutils.debug.impl.ReadWriteTransactionDebugWrapper.commit(ReadWriteTransactionDebugWrapper.java:255) ~[?:?]
at com.fujitsu.fnc.mlpce.fibertail.provider.FiberTailProviderImpl.commitTransaction(FiberTailProviderImpl.java:18451) ~[?:?]
at com.fujitsu.fnc.mlpce.fibertail.provider.FiberTailProviderImpl.openroadmServiceActivate(FiberTailProviderImpl.java:16382) ~[?:?]
at com.fujitsu.fnc.mlpce.fibertail.provider.FiberTailProviderImpl$AttServiceActivator.run(FiberTailProviderImpl.java:18692) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]


 Comments   
Comment by Tibor Král [ 27/Apr/21 ]

The augmentation is not targeting different module here. The exception is caused by something else - probably binding layer.

Comment by Robert Varga [ 18/May/21 ]

The problem is actually MandatoryLeafEnforcer, as it does not construct YangInstanceIdentifier hierarchy correctly – it effectively maps SchemaNode QNames and plays pretend they patch PathArguments. This is a very classic mapping mistake.

Comment by Robert Varga [ 18/Jun/21 ]

This needs more work, as the lookup does not quite work for example in bgp-benchmark-app, where there is a mandatory leaf, which is augmented, but in fact the entire subtree is being augmented, hence there is no corresponding augmentation.

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