runtime error "handlebars_template_parse_error" - info, tips and requests to Celigo
Hello,
I just spent about an hour chasing down the cause of a runtime error (error that you only see when the flow actually runs) "handlebars_template_parse_error". This was perplexing to me because in the handlebar expression editor for the HTTPS URI field that was throwing this error, everything looked fine. The preview worked - no errors.
My eyes weren't seeing the problem so I began the unrewarding task of systematically removing components of the expression to smoke out the offender. I found it, fixed it and I'm back on track. I'm posting here for the following reasons (it's late and I'm tried so going with list format)
- Just because the expression editor preview works without an error, doesn't mean you don't have an error. This is unfortunate and Celigo should make the editor preview and runtime behave the same.
- In my case (and maybe yours if you've searched for the error "handlebars_template_parse_error") was a non-existent field referenced in the expression. E.g. {{record.myField}} but that property isn't on the input JSON
- Request #1 to Celigo: Please make the previews as reliable as possible. It should behave the same as the runtime evaluation of the expression.
- Request to Celigo #2: Please add functionality to the handlebars editor to throw an error for a missing property. Maybe the handlebars libraries don't support this, I tried to find out but wasn't able to, but if it is supported it would be super helpful to see a list of referenced properties that don't exist.
-Steve
-
Official comment
Hello,
I have moved this post to the Integrator.io enhancement requests section.
Thanks,
Kathyana
-
Steve, instead of throwing an error if a field is missing, what if we instead always output an empty string for missing fields so that your template always evaluates, but of course a missing field will output nothing, etc... Does anyone really want an error here?
For example:
{ "myField": "{{record.myField}}" }
should evaluate to the following if 'myField' is missing from the record.
{ "myField": "" }
Thoughts?
0 -
Scott Henderson, you make a good point and I suppose an error isn't the best solution. My main concern is consistency - if the Preview is OK, then so should the runtime. If an error is going to be thrown, include the offending property.
0 -
Yeah, I agree the error message needs to be much better so that it is obvious what the issue is. I think my idea to output empty strings is flawed, and there are use cases where this would not be ideal, so this needs to be thought about more.
Regarding the preview vs runtime consistency, from a pure dynamic data processing standpoint it is a very hard problem to make these 100% consistent since the runtime has to deal with any possible record that could be processed by the flow, but the preview is only going to include a handful of possible records to help you design the flow. For example, there are many APIs out there that do not return empty fields at all, but they don't always define upfront what will get returned vs left out depending on different data conditions. We can of course do much better to collect and catalogue metadata rules for popular APIs, but this is still a hard problem to solve universally. Hope this explanation makes sense.
0 -
I understand the context and available data varies between preview and runtime, but when the same data is present shouldn't the handlebars engine yield the same result? What I mean is, if the property was missing in the preview and also missing at runtime, they should behave the same.
Your explanation is appreciated but I feel like it's addressing a different concern, or, more likely I'm misunderstanding you. Which API is utilized or which records are or are not available in the current context shouldn't effect one context throwing an error with a missing property and another allowing it, IMO.
Asked yet another way: Is a null reference in a handlebar template a fatal error or isn't it?
0 -
Sorry, I misunderstood your original post. I thought you were talking about the preview vs runtime behaving differently for slightly different records. If the preview is behaving differently than the runtime for the exact same record, then that is a bug, and I will pass this along to our QA team to flush out and ideally get fixed asap.
0 -
Kathyana Queeman why did you move this to an enhancement request? It's a bug.
0 -
Hi Steve Klett,
I've moved this back to the main custom flows section. Thanks for letting us know!
0 -
This still does not work. I am hitting the same thing.
0 -
Matt Kraemer, could you provide details of your issue, so that we can check it?
0 -
When using a SOQL Query on a SalesForce lookup, in the handlebars template preview I am receiving this on click of preview INSIDE the Handlebars template :
Select id, FX5__Ticket__c FROM FX5__Ticket_Item__c WHERE (id ='a1a8X000007CCdRQAW' AND RecordTypeID='0128c000001BlEaAAK')
My handlebars template looks like this:
Select id, FX5__Ticket__c FROM FX5__Ticket_Item__c WHERE (id ='{{@root.data.fieldfxId}}' AND RecordTypeID='0128c000001BlEaAAK')
When I am clicking "Preview" from outside of the Handlebars template on the main lookup or running the flow, I am receiving this error:
[
{
"code": "handlebars_template_parse_error",
"message": "Failed to generate salesforce.soql.query from template: Select id, FX5__Ticket__c FROM FX5__Ticket_Item__c WHERE (id ='{{@root.data.fieldfxId}}' AND RecordTypeID='0128c000001BlEaAAK'). Details: \"fieldfxId\" not defined in the model. - 1:65.",
"occurredAt": 1681306056887,
"resolved": false,
"source": "application"
}
]0 -
I figured out what was happening. The preview data was not synchronous with the input data. The input data was coming from a NetSuite search and the search criteria had been updated in NetSuite to exclude the FX Id. The preview data was still showing it was available.
0
Please sign in to leave a comment.
Comments
12 comments