It seems that we do not check if data already exists for default value of insert (last): https://datatracker.ietf.org/doc/html/rfc8040#section-4.8.5.

See PostDataTransactionUtil#submitData.

In addition, we need unit test coverage for this scenario.

The issue arises only when the device produces an error. The device generates the correct response with an appropriate NetconfDocumentedException error. This exception is then mapped to a RestconfDocumentedException in the TransactionUtil#decodeException method, along with the YangInstanceIdentifier path of the device schema, for example: "/(http://netconfcentral.org/ns/toaster2?revision=2009-11-20)toaster/darknessFactor". 

Subsequently, this RestconfDocumentedException is mapped to a JSON/XML Response in the RestconfDocumentedExceptionMapper, using the SchemaContext of the controller.  Notably, this SchemaContext does not include the models of the device.

The path of the device model is added to the "error-path" leaf and validated by the Controller SchemaContext. This validation process results in a Mapper exception, leading to a 500 error, as seen in the following log snippet:

2023-09-05T12:38:46,308 | ERROR | qtp1936609051-682 | ServerRuntime$Responder          | 172 - org.glassfish.jersey.core.jersey-server - 2.40.0 | An exception has been thrown from an exception mapper class org.opendaylight.restconf.nb.rfc8040.jersey.providers.errors.RestconfDocumentedExceptionMapper.
java.lang.IllegalArgumentException: Invalid input /(http://netconfcentral.org/ns/toaster2?revision=2009-11-20)toaster/darknessFactor: schema for argument (http://netconfcentral.org/ns/toaster2?revision=2009-11-20)toaster (after ) not found
	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:463) ~[bundleFile:?]
	at org.opendaylight.yangtools.yang.data.util.AbstractStringInstanceIdentifierCodec.serializeImpl(AbstractStringInstanceIdentifierCodec.java:53) ~[bundleFile:?]

The simplest solution for this issue would be removing validation for "error-path", similar to what is done for the "error-info" leaf.

A more complex solution would involve retaining the validation and adding the Device schema context to the RestconfDocumentedExceptionMapper. Here are suggested steps for this solution:

• RestconfDocumentedExceptionMapper will have DOMMountPointService in his constructor.
• RestconfDocumentedException will have option to add UriInfo in the constructor.
• Then we can create Inference stack for the device in method RestconfDocumentedExceptionMapper#toResponse as follows: 

if (exception.getUriInfo() != null) {
    final var identifierContext = ParserIdentifier.toInstanceIdentifier(
        exception.getUriInfo().getPathParameters(false).getFirst("identifier"),
        databindProvider.currentContext().modelContext(), mountPointService);
    final var deviceInference = identifierContext.inference();

} 

• Use this device Inference for creating a NormalizedNodeStreamWriter:

  jsonNodeStreamWriter = JSONNormalizedNodeStreamWriter.createExclusiveWriter(databindContext.jsonCodecs(),
  inference, IETF_RESTCONF_URI, jsonWriter);
  
  
  xmlNodeStreamWriter = XMLStreamNormalizedNodeStreamWriter.create(xmlWriter, inference); 

So actually we should be taking a similar approach to what we do in JSONDataTreeCandidateFormatter (and XML as well). There we talk directly to a JsonWriter and then move to JsonDataTreeCandidateSerializer – which again emits some things directly through JsonWriter and emits other things through a nested JSONNormalizedNodeStreamWriter.

In this particular case, we want to emit pretty much everything directly, except for the YangInstanceIdentifier.
In DTCL formatters the EffectiveModelContext is always local, so we get away with just emitting startLeafNode()/scalarValue() for emitting the YangInstanceIdentifier (see NETCONF-1152).
Here we do not have that luxury and need help from yang-data-codec-

: their codecs need to expose a YangInstanceIdentifier codec which just emits the encoding into an open element (in XML case) or value(String):

   XmlCodecFactory codecFactory; // corresponding to device context
   XMLStreamWriter xmlWriter; // bound to OutputStream
   xmlWriter.writeStartElement("error-path");
   codecFactory.instanceIdentifierSerializer().serializeTo(xmlWriter, path);
   xmlWriter.writeEndElement();

The resulting document contract is tied to the request URI – e.g. users reading need to understand they used yang-ext:mount and interpret things accordingly.

 I believe this is a duplicate of NETCONF-782.

Yes, it is a duplicate, but its solution is somewhat different and more in kind with eating our own dogfood.

https://git.opendaylight.org/gerrit/c/netconf/+/107877 fixes a related bug: in those two places we just do a straight-up YangInstanceIdentifier.toString().

Reported stack trace should have a tad different structure.