Malformed data in operational module, a huge sequence of `{"sysrepo:dup-inst-list-position":[null],"ietf-netconf:operation":"merge"}` about sysrepo HOT 5 OPEN

Are you using the latest devel versions of all the projects (libyang)? If so, I would need to reproduce this to fix it. The JSON printer will likely be at fault, there were similar problems fixed recently.

from sysrepo.

• libyang is at fc4dbd923
• sysrepo is at 337a6758

I do not have a reliable reproducer. I recall seeing that in the test runs of velia and/or sysrpeo-ietf-alarms a few times. The data that I attached came from one of the lab devices we have.

from sysrepo.

I made something more readable out of it but it did not help much. I think I really need the data that were printed with this bug (in XML, for example, I think it would be printed correctly that way), not sure how else to fix this.

from sysrepo.

There are no external data that are being printed by libyang, it's an error that's reported from sysrepo as a result of a corruption of its SHM data. We're building with SR_SHM_DIR set to "/run/sysrepo", and the file I attached is a verbatim copy from there.

Somehow, that file (which is only ever manipulated by sysrepo APIs) gets corrupted, our daemon terminates when a subsequent API call fails, and then the our automation which was supposed to remount the tmpfs at /run/sysrepo failed to remount, so that the subsequent restart of the daemons sees the same corruption.

from sysrepo.

I understand there are no external data, these are created push operational data being printed by the JSON printed into a file. And because of a bug the printer prints invalid data. All I am saying is that I will need that data (as libyang structures, parsed from an XML file, for example) so that I can print them and debug the problem.

from sysrepo.