GCU: silence transient YANG leafref ERR during patch-sort search

[Xichen96]

FullConfigMoveValidator is invoked speculatively during the patch-sort search to check whether a candidate move results in a YANG-valid config. Forward leafref references produce expected transient validation failures; the sorter already handles these as a prune signal via the returned (False, error) tuple.

However, sonic_yang.loadData logs a LOG_ERR "Data Loading Failed" line to syslog on every exception (log-and-throw antipattern) before raising, so each speculative probe leaks an ERR to syslog. In practice a single config apply-patch during the GCU test suite can emit 100+ such lines, which trips loganalyzer and makes real errors hard to find.

This change threads a quiet= kwarg through:
ConfigWrapper.validate_config_db_config(..., quiet=False)
-> sonic_yang.loadData(..., quiet=quiet)

and makes FullConfigMoveValidator.validate pass quiet=True. Non- speculative callers (e.g. final target-config validation) keep the existing default (quiet=False) and continue to log on real errors.

Depends on sonic-net/sonic-buildimage: quiet= kwarg added to sonic_yang_ext.SonicYangExtMixin.loadData.

Validated on DUT with sonic-mgmt generic_config_updater subset (dhcp_relay, eth_interface, vlan_interface, portchannel_interface, cacl, lo_interface, bgp_prefix, syslog):
BEFORE: 31P/1F/3S/3E, 231 apply-patch, 115 Data Loading Failed ERR
AFTER: 31P/1F/3S/2E, 231 apply-patch, 34 Data Loading Failed ERR
Remaining ERR lines are from legitimate non-speculative callers.

What I did

Silenced the Data Loading Failed LOG_ERR spam that the GCU patch sorter emits during its speculative search, without altering the sorter's control flow or changing behavior for any non-speculative caller.

Two files in generic_config_updater/:

• gu_common.py — ConfigWrapper.validate_config_db_config gains a quiet=False kwarg, forwarded to sy.loadData(..., quiet=quiet).
• patch_sorter.py — FullConfigMoveValidator.validate passes quiet=True, since every failure there is an expected search-prune signal.

No other caller is changed. FullConfigMoveValidator's return semantics (is_valid, error) are unchanged, so real failures still surface through the returned tuple as before.

Work item tracking (Microsoft ADO): 36655183 ([SONiC_Baseline][Failed_Case][dhcp_relay.test_dhcpv4_relay][test_dhcp_relay_with_non_default_vrf]) and 36656583 ([SONiC_Baseline][Failed_Case][dhcp_relay.test_dhcpv4_relay][test_dhcp_relay_with_different_non_default_vrf]).

Depends on sonic-net/sonic-buildimage# (adds the quiet= kwarg to SonicYangExtMixin.loadData in sonic-yang-mgmt). Must merge after that PR.

How I did it

# generic_config_updater/gu_common.py
-def validate_config_db_config(self, config_db_as_json):
+def validate_config_db_config(self, config_db_as_json, quiet=False):
     ...
-    sy.loadData(config_db_as_json)
+    sy.loadData(config_db_as_json, quiet=quiet)

# generic_config_updater/patch_sorter.py — FullConfigMoveValidator.validate
-    is_valid, error = self.config_wrapper.validate_config_db_config(simulated_config)
+    # Speculative validation during patch-sort search. Transient leafref
+    # failures are expected; sorter handles them via returned (False, err).
+    is_valid, error = self.config_wrapper.validate_config_db_config(
+        simulated_config, quiet=True)
     return is_valid, error

How to verify it

Run the sonic-mgmt generic_config_updater test subset against a T0 DUT and count "Data Loading Failed" lines in /var/log/syslog during the run.

Validated on a T0 (20251110.19) with 8 test files (dhcp_relay, eth_interface, vlan_interface, portchannel_interface, cacl, lo_interface, bgp_prefix, syslog):

BEFORE (stock):

• 31 passed, 1 failed, 3 skipped, 3 pytest errors
• 231 apply-patch events during the run
• 115 Data Loading Failed lines in syslog
• Duration 1:30:33

AFTER (fix):

• 31 passed, 1 failed, 3 skipped, 2 pytest errors
• 231 apply-patch events during the run
• 34 Data Loading Failed lines in syslog
• Duration 1:27:42

The remaining 34 ERR lines are from legitimate non-speculative callers (final target-config validation) — preserved behavior, not a bug.

Also ran dhcp_server/test_dhcp_server_port_based_customize_options with the fix: 2/2 passed, 8 apply-patch events, 0 Data Loading Failed ERR, 0 leaked sonic_yang ERR.

Default behavior (quiet=False) is exercised by every existing GCU unit test; no unit tests needed modification.

Previous command output (if the output of a command-line utility has changed)

New command output (if the output of a command-line utility has changed)

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR reduces syslog noise emitted during Generic Config Updater (GCU) patch-sort’s speculative YANG validation by threading a quiet= flag into the validation path used for search/pruning, while preserving existing logging behavior for non-speculative (final) validation.

Changes:

• Add quiet: bool = False kwarg to ConfigWrapper.validate_config_db_config() and forward it to sonic_yang.loadData(...).
• Update FullConfigMoveValidator.validate() to call validate_config_db_config(..., quiet=True) during patch-sort search.
• Add a unit test asserting FullConfigMoveValidator passes quiet=True to the config wrapper.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
generic_config_updater/gu_common.py	Adds quiet kwarg to config validation and forwards it to YANG load/validate call.
generic_config_updater/patch_sorter.py	Uses quiet=True for speculative validation in FullConfigMoveValidator.
tests/generic_config_updater/patch_sorter_test.py	Adds regression test verifying quiet=True is passed during speculative validation.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Copilot / name: Copilot (36f11d3)
• ✅ login: Xichen96 / name: Xichen96 (36f11d3, 438ccd8, a360876)

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

The change is not in 202511 yet. @Xichen96, please manually create the cherry pick PR for branch 202511.
You can ping the release branch owner(github account: ) to approve your cherry pick PR.
If this change is already in 202511, please comment "already in 202511". Thanks!

_{---Powered by SONiC BuildBot}

[Xichen96]

already in 202511

[Xichen96]

#4484

[mssonicbld]

The cherry pick conflict has been handled manually. Removing cherry pick conflict label...

_{---Powered by SONiC BuildBot}