`resource set` errors unexpectedly when `test` is undefined and `set.preTest` isn't explicitly `true` in resource manifest

[michaeltlombardi]

Prerequisites

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

Steps to reproduce

When implementing a command-based DSC Resource without explicitly defining test, the dsc resource set command errors when the preTest key is undefined or is set to false in the resource manifest's set property.

dsc resource get and dsc resource test both work as expected.

I discovered this when working with the example implementations in #85.

This is the snippet of the resource manifest with the schema trimmed for readability:

{
    "manifestVersion": "1.0",
    "type": "TSToy.Example/gotstoy",
    "version": "0.1.0",
    "description": "The go implementation of a DSC Resource for the fictional TSToy application.",
    "get": {
        "executable": "gotstoy",
        "args": ["get"],
        "input": "stdin"
    },
    "set": {
        "executable": "gotstoy",
        "args": ["set"],
        "input": "stdin",
        "preTest": false,
        "return": "state"
    },
    "schema": {}
}

When preTest is removed, the command returns the same error. When preTest is set to true, the command runs without an error, but also without validating the state beforehand.

Expected behavior

Either of the following:

1. DSC calls the resource's `set` command if DSC's synthetic `test` for the resource indicates that the resource isn't in the desired state
1. DSC calls the resource's `set` command without checking if the resource is in the desired state.

Actual behavior

DSC returns the error message:


Error: Not implemented: test

Error details

No response

Environment data

N/A

Version

(build from main)

Visuals

No response

[SteveL-MSFT]

The test fn of DscResource implements the synthesized test implementation, we probably just need to have set call this rather than invoke_test directly.

[anmenaga]

The 'Expected behavior' mentioned in this issue is different than expected behavior that is currently in the code. @SteveL-MSFT needs to review this.

[anmenaga]

To be clear: what is synthesized test ?

[SteveL-MSFT]

@anmenaga if a resource doesn't implement test, dsc.exe will synthesize this by doing a get and comparing the expected result to the actual result and report it back. Resources only need to implement test directly if a direct comparison of values isn't sufficient, perf implications, or other reasons.

[mgreenegit]

Discussion question, which of these is more true?

1. dsc set - when explicitly called should always run test (or synthesized test) first. If test returns true then the set operation should not execute.
2. dsc set - when explicitly called does not need to run test, it should always execute the set operation.

[michaeltlombardi]

Discussion question, which of these is more true?

1. dsc set - when explicitly called should always run test (or synthesized test) first. If test returns true then the set operation should not execute.
2. dsc set - when explicitly called does not need to run test, it should always execute the set operation.

My naive expectation would be 1 - if I wanted to run set for a specific resource without the friendly handling, I would call its set command directly myself. I would expect that if I'm using dsc as the caller, it is doing the work of running test first for me unless I tell it not to, like with a --no-test flag or something.

[SteveL-MSFT]

I agree that dsc here is expected to "fill in the gaps", so if you really want a direct set, you can just call that resource directly as a command-line which is probably only useful to developers of that resource.

[SteveL-MSFT]

This was fixed via https://github.com/PowerShell/DSC/commit/d817869ae5ab7ddd2169c5efd0bb7199512268ec