[bug] Target condition containing "IN" works in Portal but fails upon create

[papakpmartin]

Using Azure Portal, if I create a deployment that has a target condition like tags.environment IN ['foo','bar'] OR deviceId IN ['a','b','c'], that condition finds all expected devices when I “Find Devices” on that blade, but when I attempt to “create” that deployment, I get an error: InvalidConfigurationTargetCondition.

I did see the question from @digimaun on a similar issue (#347), and the answer is yes, I'm certain that the target condition works ini the portal when setting things up, and that API request returns a HTTP 200.

I can't seem to find an authoritative target condition reference, but I do note that IN is not listed at https://docs.microsoft.com/en-us/azure/iot-edge/module-deployment-monitoring?view=iotedge-2020-11#target-condition

So I think that either something is wrong and IN should be working as expected, and this just isn't well documented, or IN is not a supported target condition, in which case it should not be working in the Portal when setting up a Deployment.

[digimaun]

Hey @papakpmartin thanks for highlighting this issue. Agreed there is a disconnect in what different operations support here -- to capture what's happening in a repro/recap summary...

In this section of the portal edge deployment create flow

There are two API operations in play both configurations/testQueries and device/query (equivalent of az iot hub query) have successful 200 response codes returning KPIs

However when submitting for creation there is the 400 InvalidConfigurationTargetCondition error raised by the service. Ideally there could be clarified docs for this case, and the UX could block/more optimally surface what target conditions will work for a deployment.

We'll need to do some investigation for next steps, but in the meantime I hope you are able to construct your target condition in a different way as a workaround.

[papakpmartin]

I am. It's a little cumbersome to break everything up into ORs, but it works.

Thanks for your consideration!

[chieftn]

Hi @papakpmartin and @digimaun thank you for raising this disconnect. As @digimaun suggests, the disconnect is between the testQueries method and the actual {put} of the updated configuration object during save. TestQueries is a validation method returning a payload indicating if the target condition has an error. Specifically, that method returns a payload of:

{ ..., targetConditionError: null } if there is no error with the target condition.
If the targetConditionError value is not null, the validation fails.

In this case, the testqueries method indicates there is no problem with the IN query but the {put} is still being rejected. We'll look into the disconnect to determine whether testQueries is accurate or the {put}'s internal validation.