Skip to content

_inDesiredState not being respected in test state output #674

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
3 tasks done
JohnMcPMS opened this issue Mar 6, 2025 · 0 comments · Fixed by #676
Closed
3 tasks done

_inDesiredState not being respected in test state output #674

JohnMcPMS opened this issue Mar 6, 2025 · 0 comments · Fixed by #676
Labels
Issue-Bug Something isn't working Need-Review
Milestone

Comments

@JohnMcPMS
Copy link
Collaborator

Prerequisites

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

Summary

A resource that implements a test command and returns state with the _inDesiredState property as documented still has the inDesiredState top level property calculated by the property diff.

Related to #108, although my test case is actually the inversion of the described reason to add _inDesiredState (no property diff, but not in desired state).

Workarounds:

  1. Fail if relevant properties are not provided to test rather than using defaults.
  2. Make any relevant properties required.
  3. [BEST] Return stateAndDiff so that the resource can control the property diff.

Steps to reproduce

First, implement a resource with a test command that returns state with an _inDesiredState property. Unfortunately, it looks like only the archived registry resource uses it so there isn't an easy repro.

The fragment from my resource manifest:

  "test" : 
  {
    "args" : 
    [
      "dscv3",
      "test-file",
      "--test"
    ],
    "executable" : "wingetdev",
    "input" : "stdin",
    "return" : "state"
  },

By allowing a default value for one of the resource properties, the desired state to actual state diff will be empty. Since the code only uses whether diff_properties is empty, and only values in the desired state that are different in the actual state are included, the diff is calculated as empty.

Sample output from calling my resource:

> @{ path = "E:\Temp\winget-dsc-test.txt" } | ConvertTo-Json | wingetdev dscv3 test-file --test
{"_exist":true,"_inDesiredState":false,"content":"Contents!","path":"E:\\Temp\\winget-dsc-test.txt"}

And output from calling dsc resource test:

> @{ path = "E:\Temp\winget-dsc-test.txt" } | ConvertTo-Json | dsc resource test --resource Microsoft.WinGet/TestFile -f -
desiredState:
  path: E:\Temp\winget-dsc-test.txt
actualState:
  _exist: true
  _inDesiredState: false
  content: Contents!
  path: E:\Temp\winget-dsc-test.txt
inDesiredState: true
differingProperties: []

If I provide an empty string for the content property, the diff is no longer empty and the result is correct:

> @{ path = "E:\Temp\winget-dsc-test.txt"; content = "" } | ConvertTo-Json | E:\Temp\dsc-rc\dsc.exe resource test --resource Microsoft.WinGet/TestFile -f -
desiredState:
  path: E:\Temp\winget-dsc-test.txt
  content: ''
actualState:
  _exist: true
  _inDesiredState: false
  content: Contents!
  path: E:\Temp\winget-dsc-test.txt
inDesiredState: false
differingProperties:
- content

Expected behavior

The top-level inDesiredState property always has the same value as the _inDesiredState property returned by the test command.

Actual behavior

The inDesiredState property is always based on whether the property diff is empty.

Error details

Environment data

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

Version

3.0.0

Visuals

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug Something isn't working Need-Review
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants