doc: lyd_parse_op has special requirements when parsing notifications
#2448
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As confirmed by Michal, the parsing code will try to read the `notifications` module, if it is available, or if the parsed data from the `ietf-yang-types` module are not available. As a result, a context which has not loaded the `notifications` module *and* which was not created with LY_CTX_SET_PRIV_PARSE will return an error when parsing notifications.
Member
|
That is not accurate. Normal context will work fine because it keeps the parsed modules and nothing else is needed. It is specific to sysrepo that it frees the parsed modules to save some memory except when the |
jktjkt
added a commit
to CESNET/rousette
that referenced
this pull request
Nov 10, 2025
- the prefix of the "ietf-netconf-with-defaults" module has changed, - RPC parsing needs a flag to reject unknown input data nodes, - due to the "printed context" mess, we now need an extra flag to ensure that we can still access the YANG schema source. The last item is interesting. We could also read directly from the on-disk location, but that looks a bit meh. It's also a bit annoying that one has to change this thing over a lot of places, but I think that this is much nicer than trying to force a change over an existing connection (e.g., via a connection-specific call in the Server::Server ctor which might hit some internal locks depending on how the sysrepo state look like). I was considering adding a wrapper for `ly_ctx_get_options()` and a check in Server::Server, but then I decided that I won't bother. Oh, and this "disable printed context" is also needed for the RESTCONF *client* which is used in the unit test. The `lyd_parse_op` cannot parse notifications *iff* the `notifications` module from RFC 5277 is missing *and* when the libyang context does not have the "parsed" info from the `ietf-yang-types` available. The printed context, as provided by sysrepo, does not have that data available. This is all papered over as long as the context flag setting works, which is the case with post-4.2.4 version of sysrepo (still untagged). Yay. We still set these flags to a single value in all of the unit tests and in the main() as well to maintain the remaining bits of our sanity, of course. Change-Id: I142f650affb53411b5c1dd81311400a2aa6dec20 Depends-on: https://gerrit.cesnet.cz/c/CzechLight/dependencies/+/8990 Bug: CESNET/libyang#2448 Depends-on: sysrepo/sysrepo@6dc5641
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As confirmed by Michal, the parsing code will try to read the
notificationsmodule, if it is available, or if the parsed data from theietf-yang-typesmodule are not available. As a result, a context which has not loaded thenotificationsmodule and which was not created withLY_CTX_SET_PRIV_PARSEwill return an error when parsing notifications.