Defect: Short circuit evaluation needed on message tool

[SeanAdams]

Summary: The message tool fails on evaluating the error message formula even if there are zero rows in the record set and the value is set to "before rows where 1=1".   If there are no rows then the message tool should not evaluate the formula part of the error message at all.

Error:

Error: Message (80): Parse Error at char(38): Unknown variable "response_error_code"

Configuration to replicate:

• On the back of a download tool, I'm checking if there is an error response coming from the Rest API using a simple filter
• If there is an error - looks like this:
  • {"response":{"status":"error","error":{"code":301,"message":"Invalid session key."}}}
• Use a JSON parse to interpret this; and a cross tab to make it usable and then it looks like this

Error Case:

• If the filter tool shows that there is no error response from the rest call
• Then the JSON parse has no rows
• And the transpose tool has no rows and none of these columns
• And the error message fails even though there are no error rows

Remediation:

• Change the logic in the error message tool to a short circuit evaluation so that if there are no rows going into the tool, then it doesn't bother to evaluate the formula

Detailed Images:

[RachelW · Accepted solution]

@SeanAdams Thanks for bringing this to our attention. It would be a great help if you would submit defects to our customer support team, so that we can log them and escalate accordingly. 

(Marking this as duplicate, since we'll log it through the defect progress rather than idea process.) 

@MargaritaW

[MargaritaW]

Thanks @SeanAdams and @RachelW.

We (Support) will create a case for this and reach out to Sean if we have further questions and/or updates.

+ @AndrewL

[RachelW]

Splendid! Thanks @MargaritaW!

[JessicaS]

Hi All,

Just a note from the moderation team.  We have moved this post over to the designer discussions area for greater visibility.

Thanks,

[SeanAdams]

Been exchanging e-mails with @KevinW on this - and this is not an issue that can be resolved with a support ticket, since it's a baked in issue with the way the tools work.

Let me provide more colour - unfortunately I can't provide a sample workflow because it's company property, but I'll capture the essence.

What is short-circuit evaluation?

• Any boolean condition which evaluates (A and B) will give you true only when both A and B are true
• So - if A is false then you know there's no point in evaluating B because the entire expression will fail
• So many software languages and compilers deliberately short-circuit this by not even evaluating B if A is false

How does that apply here?

• If you build a workflow that takes in content that has dynamic fields - then the downstream tools don't know what fields exist until run-time
  • Example is the flow @LordNeilLord did a while ago that scanned all the submissions from all the weekly challenges to see what tools people use
• Now - if the folder is empty - then the dynamic input tool will return no rows, and the XML parser downstream will not add any columns
  • Again - using Neil's example -  if the folder that you scan has no alteryx canvasses  - then the dynamic input safely returns no rows; as does the XML parse (which also adds no columns)
• Now downstream we have a filter; or unique; or message tool that has logic based on a field that would normally exist if the dynamic input had >0 rows
  • for example - filter canvasses based on the tool count
• However - because the XML parse had no rows - there are no columns added so the "Tool Count" field does not exist, so filter failed

But surely this sounds logical?

• It does sound logical - in fact Alteryx is behaving according to design
• However - this design can be improved
• Applying short circuit
  • If there are no rows in the input set - then evaluating the filter expression is not needed (short circuit) because we know that no rows can ever go down the True leg if there are no rows
  • If there are no rows coming in - then any message tool will not fire - don't bother evaluating the expression
  • This applies across most of the tools - if there are no rows coming in - don't waste time evaluating any functions or predicates in the tool because they will not evaluate to true

So this is more of an idea than a support ticket - adding short-circuit evaluation to most of the tools will reduce run-time errors where you have a zero-rowset result from a dynamic tool - while at the same time having zero impact when there's a non-zero rowset - so it seems like a quick way to make Alteryx less prone to unnecessary run-time errors