I sat down today and started getting the following errors for an action invoked via fetch from functions V1:
{
"errorCode": "INVALID_ARGUMENT",
"errorName": "FunctionExecutionFailed",
"errorInstanceId": "a5e78015-9118-46a6-9c42-8fb06ba3749c",
"parameters": {
"functionRid": "ri.function-registry.main.function.9118284d-3050-4c58-a6c9-7fb6b8971e9a",
"functionVersion": "RuleAndExecutedFunctionVersions{ruleFunctionVersion: 7.0.3, executedFunctionVersion: Optional[7.0.3]}",
"message": "Unterminated string in JSON at position 1108 (line 1 column 1109)",
"stacktrace": "SyntaxError: Unterminated string in JSON at position 1108 (line 1 column 1109)\n at JSON.parse (<anonymous>)\n at t.recall (UserCode:2:508459)\n at async m.createCommunicationsTasks (UserCode:2:464736)\n at async s.value (UserCode:2:443541)\n at async De (FunctionsIsolateRuntimePackage:2:1133035)\n at async he.executeFunction (FunctionsIsolateRuntimePackage:2:1133542)\n at async userFunction (FunctionsInitialization:10:43)"
}
}
My JSON payload is fine and I can parse and strinify it just fine in the debugger:
JSON.stringify(JSON.parse(body), null, 2)
{
"parameters": {
"query": "Create a RFP for Northslope and Rangr to deliver a tariff solution on Foundry. The solution must include support for pricing models, simulations, and A/B testing of the outcomes. We expect this to be an 4 week engagement requiring 3 Python engineer, 1 TypeScript engineer, and 2 SME on developing pricing models. Then email me the responses. The company is John Doe's Manufacturing and there address is 123 main street dallas tx, 75081",
"userId": "cadf16c6-76c8-4ff2-8716-889f8797d547",
"xReasonEngine": "sales"
},
"options": {
"returnEdits": "ALL"
}
}
Has something changed in Foundry? I will continue to troubleshoot on my end but I haven’t deployed any changes since yesterday when this was all working.
Executing the exact same request with cURL works:
curl -X POST "https://$URL/api/v2/ontologies/ontology-$RID/actions/create-communication-tasks-with-vici/apply" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
--data-raw '{"parameters":{"query":"Create a RFP for Northslope and Rangr to deliver a tariff solution on Foundry. The solution must include support for pricing models, simulations, and A/B testing of the outcomes. We expect this to be an 4 week engagement requiring 3 Python engineer, 1 TypeScript engineer, and 2 SME on developing pricing models. Then email me the responses. The company is John Does Manufacturing and there address is 123 main street dallas tx, 75081","userId":"cadf16c6-76c8-4ff2-8716-889f8797d547","xReasonEngine":"sales"},"options":{"returnEdits":"ALL"}}'
{"validation":{"result":"VALID","submissionCriteria":[],"parameters":{}},"edits":{"type":"edits","edits":[{"type":"addObject","primaryKey":"6ac1e68c-732e-4ba2-8f72-7e85095ef318","objectType":"Communications"}],"addedObjectCount":1,"modifiedObjectsCount":0,"deletedObjectsCount":0,"addedLinksCount":0,"deletedLinksCount":0}}
What is strange is the issue has gone away this morning. I’m not sure what is going on here. I think the root cause is an issue with the LLM that is backing this function. I’ve pasted the code below. There is one function in this call stack called recall
which provides a grounding context and uses a regex (I know, I know, practicing regex without a license) to extract the JSON. My guess is for whatever reason Flash Gemini was sending back something that caused that regex parsing to barf, or it send back totally invalid JSON.
I’ve attached some screenshots of the tracing solution I use in Foundry to spot issues. I am not tracing recall directly though. I’m going to add tracing to that function to help spot the source of the issue moving forward. What is strange though is the fact that I tried requests over and over and they failed every time. Usually the behavior of the models would be to fail in some cases and succeed in others. Now ever test is passing. Hopefully, there is no caching behavior in the actions end points themselves. I don’t think there is, but if there is I would recomend turning it off by default and allowing developers to send their own cache policy in the requests.