Filter Array Issue or Platform Issue?

[foff]

I will share some screenshots and you tell me where the issue is and how i find the answer to this....

Filter array error

please note......

    

wonder if anyone from MS can comment on this....

[wskinnermctc]

Show screenshots of the steps before you run the flow. It's difficult to tell by just looking at the error.

[foff]

i think you missed the point.... 🙂

The name of the action that failed is "Filter array 3" and the error report generated on the right states "Remove_LZ_Sales_from_the_array".

something is broken.... and it is not my flow. the filter array action is repeated in every switch statement...

Here is the flow in a bit more detail

[wskinnermctc]

Thank you, that is helpful. I do get the point, and it is a strange error, so I wanted to see if you had anything else going on with the flow that might provide some evidence of the issue.

Did you copy and paste the action from clipboard? 

Was there ever a step in the flow named "Remove_LZ_Sales_from_the_array"?

Is this flow co-owned or being edited by multiple users?  

I think the problem is with the Switch 3 and not the Filter Array step. If the Switch was copy and pasted it probably has some system code or something that carried over with it. Unfortunately you can't Peek Code on the Switch.

I would try replacing the Switch. And don't use the clipboard.

[foff]

Thanks for the reply. I might have initially copied that action, but then deleted and recreated it as part of trying to resolve the error. There are other steps with very similar names which i constantly have to rename. I also "peeked" at the code but nothing special there.

I wouldn't have copied the switch itself. And I cannot copy a branch of the switch statement so it can't be that. (if that made sense)

[foff]

update

Here is where it gets interesting...

Looking at the switch case (case-327) which should not fire as the switch value is 302 - even if it wasn't a match it should still not trigger - but that is the "filter array" that is triggering an error. But it shouldn't even be touched! How now? Weird.

[foff]

same again...

but when you expand the action that shouldn't even be run you get..

and i deleted the previous "filter array" action and recreated it.

[wskinnermctc]

With all of those problems I would completely delete the flow and start over.

I never use copy clipboard because it always ends up causing me a problem. And it is either with the copy action or the renaming action, PA always wants to give trouble.

I literally had a similar example to you happen a few minutes ago. I was editing a flow and testing. I pressed test flow and noticed the flow ran showing the old actions I had just deleted (some testing Compose steps and other stuff). 

Since the flow has to save before testing, there is no way I ran the flow without saving after I deleted those steps. So I backed out of the flow completely and refreshed the browser. Came back into the editor and the flow was how it was supposed to be with those steps removed.

I'm thinking that there are some names and/or references that power automate uses to build a flow in the background, and when things are changed too rapidly or moved around, it might not refresh those names properly.

Also I think these issues happen when using the "Test" automatically with a recently used trigger. It is like the current Test flow is recalling the past data, and some ghosts from that past data steps get fed into the new flow.

Long story Long, I don't have the correct solution for you other than share things I do to help prevent some weird issues

• Don't copy and paste steps
• Don't rename things that have following steps connected to it. (Primarily Data type actions like Compose or Filter Array since they seem to be the main culprit) 
• Don't use the Test button too rapidly
• Try not to test automatically with recent trigger on the same item a dozen times, just create a new item or whatever to let the flow trigger normally. I think it kind of refreshes data references like that.
• Save and back out of the flow editor completely and refresh the browser the moment you start getting weird Rename problems.
• Completely deleting flows and remaking new ones is sometimes the best way, consider it extra practice.
  • I had a very large complicated flow (at least 100 steps and at a dozen http requests) I had to completely remake due to me adding scopes and renaming items. It just wouldn't sort out and work correctly after I made a lot of changes. Ever since then I've always been cautious about how I name or change steps. That flow ended up having 300 step type actions and I did not want it to break.

Here is a recent example of the renaming issue that I have had frequently

https://powerusers.microsoft.com/t5/Building-Flows/Flow-Editor-Stuck-on-Renaming-Action/m-p/2266853#... 

Hope this helps, sorry you're having an issue, maybe someone has a legitimate answer

[foff · Accepted solution]

Thank you for that - i do appreciate the time you took to have a look and share your best practices.

The fact that you have just had something similar, to me, indicates somethings going on in the back end. Try doing a Parse JSON action and then using the values from the parse json in your flow... good luck 🙂 I have a case open with MS on that very topic. But I suggest you try it.

I pretty much do what you do also. I know about the renaming issues - so i always rename early and if i have to do a rename, i know to go back down the flow and refresh all the steps that reference the renamed step. I also exit out of PA completely and then go back into it as a kind of "refresh"

As for testing, I use it a lot, but I also understand why and how I can use the automatic testing. It obviously depends on what the flow does. This current flow sets permissions in Sharepoint and yes, I cannot auto test because once it has run on the sharepoint folder, if i where to run it again, the folder has already been modified so the test will fail. But for other types of flows, I use testing a lot.

I also have issues with copying steps and barely use it. Sometimes it works, sometimes it doesn't do anything. Obviously renaming issues when doing that and also the internal dynamic components have to be changed because they still reference the original parent structure from where it was copied.

I also discovered the main culprit behind the main issue of this post.

The switch statement.

So the value being evaluated is a string (from dataverse) although it only contains whole numbers.  PA must be doing a conversion/detection an decided that the 327 that i put in the case doesn't match. Then using single quotes appeared to fix filter array issue but failed to evaluate correctly. Using double quotes in the case statement seems to wok as expected but this is what PA shows me.

Oh the joys.

[foff]

apologies - here is a slightly better screenshot showing the same error as above 🙂

[foff]

Final thoughts

This entire thread was triggered because the error message was wrong! In fact more than that, i think the entire switch operation is faulty.

Here's why:

The switch operation couldn't evaluate the values passed and compare it to the case provided. Fair enough, but the whole purpose of the switch operation is that if the value doesn't equate to the case statement, then the "default" branch is followed. Regardless of the "type" of value - it either is a match or it isn't a match. SIMPLE. If it isn't a match for any case because of the actual value or type mismatch, then the "Default" path is followed. Else, the case which matches is followed.

It really is that simple.

In this case, PA couldn't evaluate the case statement and then simple tried to follow all paths and generated rubbish error messages from the next line. How stupid is that.

Anyway, have fun.

[Matthy79]

Hello @foff,

the whole switch is a bug by design. I raised a ticket one year ago and got an answer that the team will fix it in the next 6 months. Nothing happened. I try to avoid it whenever it is possible. But if you use it you already found out that you need the same types (like anywhere else). "If" also doesn't work if you provide strings and integers to be compared but you will receive a better error message.

Since Power Automate tries to convert things like numbers and booleans and the case step of the switch isn't able to understand an expression, things get more complicated. Microsoft designed a workaround that you can put things under double quotes (") to tell Power Automate that it is a string. This gets funny if those double quotes are part of the value you want to compare to.

But in your case you can write the numbers like this inside the case action:

"302"

and it will work but lead to wrong flow histories.

I saw you already realised all of that but I wanted you to know that you are not alone with all the headaches Power Automate is causing. Maybe you can share the outcome of your ticket.

[foff]

Thanks @Matthy79 - I appreciate your comments. It's true there are these "bugs" (see what i 'did' there 😉 ) and we learn to live with them. They are infuriating and cause unnecessary frustration and delays. I mean i do enjoy power automate, but at the same time, there are so many things that are buggy. Thanks for your post and i will try and keep you updated on my other ticket....