DSC/AssertionGroup reports as out of state for test method even when all instances are in the desired state

[michaeltlombardi]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

When using the DSC/AssertionGroup with the dsc config test command, I expect that the resource group is considered to be in the desired state when all instances in the group are in the desired state.

However, the resource group returns inDesiredState as false and lists the resources property in the differingProperties result field.

Define the following configuration on a 64-bit system as repro.dsc.config.yaml:

$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
resources:
  - name: Operating System Assertion
    type: DSC/AssertionGroup
    properties:
      $schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
      resources:
        - name: Is64BitOS
          type: Microsoft/OSInfo
          properties:
            bitness: '64'

Expected behavior

cat ./repro.config.dsc.yaml | dsc config test

results:
- name: Operating System Assertion
  type: DSC/AssertionGroup
  result:
    desiredState:
      $schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
      resources:
      - name: Is64BitOS
        type: Microsoft/OSInfo
        properties:
          bitness: '64'
    actualState:
      results:
      - name: Is64BitOS
        type: Microsoft/OSInfo
        result:
          desiredState:
            bitness: '64'
          actualState:
            $id: https://developer.microsoft.com/json-schemas/dsc/os_info/20230303/Microsoft.Dsc.OS_Info.schema.json
            family: Windows
            version: 10.0.22621
            edition: Windows 11 Enterprise
            bitness: '64'
          inDesiredState: true
          differingProperties: []
      messages: []
      hadErrors: false
    inDesiredState: true
    differingProperties: []
messages: []
hadErrors: false

Actual behavior

cat ./repro.config.dsc.yaml | dsc config test

results:
- name: Operating System Assertion
  type: DSC/AssertionGroup
  result:
    desiredState:
      $schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
      resources:
      - name: Is64BitOS
        type: Microsoft/OSInfo
        properties:
          bitness: '64'
    actualState:
      results:
      - name: Is64BitOS
        type: Microsoft/OSInfo
        result:
          desiredState:
            bitness: '64'
          actualState:
            $id: https://developer.microsoft.com/json-schemas/dsc/os_info/20230303/Microsoft.Dsc.OS_Info.schema.json
            family: Windows
            version: 10.0.22621
            edition: Windows 11 Enterprise
            bitness: '64'
          inDesiredState: true
          differingProperties: []
      messages: []
      hadErrors: false
    inDesiredState: false
    differingProperties:
    - resources
messages: []
hadErrors: false

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      7.3.6
PSEdition                      Core
GitCommitId                    7.3.6
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Version

Latest build from main

Visuals

No response

[SteveL-MSFT]

The intent of the AssertionGroup is to test some requirements before proceeding with the rest of the configuration. Due to this nature, it internally always calls test and returns a configuration test result. So the naive configuration comparison will see that the result doesn't match. So the code could be changed to look to see if the config test result has inDesiredState = true and skip the comparison altogether, but then it's a bit inconsistent for anyone looking at the resulting JSON. Is there a more complete example where the current behavior will fail unexpectedly?