You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reconciliation of Cluster resources that set volumeAttributesClassName in a pvcTemplate always issues a redundant, empty PATCH operation against each of the cluster's PVCs, even when the PVC already carries the expected value. This is caused by an incorrect comparison here:
The guard in reconcileVolumeAttributeClass compares two *string pointers with ==, which tests pointer identity rather than value equality. Since the template's pointer and the PVC's pointer never share an allocation, the comparison only succeeds when both sides are nil — with a volumeAttributesClass configured, it fails on every reconciliation.
The impact is limited to wasted API-server traffic: because the assigned value is identical, the computed merge patch is empty ({}), so the PVC is not actually modified. The existing unit test doesn't catch this because it assigns the same pointer to both the PVC and the template.
Your analysis is correct. The comparison at line 111 [1] checks pointer identity (== on two *string values) rather than dereferenced value equality, so it will always fall through to the PATCH path when volumeAttributesClassName is set — even when the values are already identical.
As you noted, the existing unit test for the "does nothing if VolumeAttributesClassName is already the expected value" case [2] reuses the same string variable for both the PVC and the template, which means both pointers share an address and the == check happens to pass — masking the bug in tests.
A fix would be to replace the pointer comparison with a value-aware comparison, e.g. using ptr.Equal:
And the test should be updated to use independently allocated *string values (e.g. via ptr.To("value") for each side) to properly exercise the comparison.
Activity
dosubot commentedon Jul 14, 2026
Hi @andrew-farries! I'm Dosu and I'm helping the CloudNativePG team.
Your analysis is correct. The comparison at line 111 [1] checks pointer identity (
==on two*stringvalues) rather than dereferenced value equality, so it will always fall through to the PATCH path whenvolumeAttributesClassNameis set — even when the values are already identical.As you noted, the existing unit test for the "does nothing if VolumeAttributesClassName is already the expected value" case [2] reuses the same string variable for both the PVC and the template, which means both pointers share an address and the
==check happens to pass — masking the bug in tests.A fix would be to replace the pointer comparison with a value-aware comparison, e.g. using
ptr.Equal:And the test should be updated to use independently allocated
*stringvalues (e.g. viaptr.To("value")for each side) to properly exercise the comparison.To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
fix(pvc): use `ptr.Equal` for `VolumeAttributesClass` equality check (#…
fix(pvc): use `ptr.Equal` for `VolumeAttributesClass` equality check (#…
fix(pvc): use `ptr.Equal` for `VolumeAttributesClass` equality check (#…
fix(pvc): use `ptr.Equal` for `VolumeAttributesClass` equality check (c…