Hey, so I have my workflow where I call an LLM to process some tickets and then merge the output of the LLM with said tickets. That seems to work fine, but I have tried to implement retry logic because the LLM returns an error way too often. The problem lies in that it sometimes creates more than one run, that persists even after a Merge node (append), when the LLM returns an error.
What is frustrating is that I have executions where the LLM returns an error for some items, but the logic works as intended and all the runs get appended into one.
The error state returned by the LLM was an item that looked like this:
About the retries, there are two control points (IF nodes), one checks if there was an error from the LLM and the other one checks if the max number of retries has been reached. Iâm not sure if you refer to that
Iâm trying to stay within Googleâs environment for now, plus gemma is free to use and effective for my usecase (when it works).
I avoided using agents because I donât know how they work and I could figure out the steps to create this myself, but if they work and this doesnât, well
I have tested the flow, and it seems to be working fine!
And I can understand your problem with the AI being unpredictable that is why I would recommend that if you can, then consider using the AI agent where you can just specify a clear system prompt for behavioural control and can attach an output parser, which would help you regulate the unpredictability of the AI. Also, if your use for the AI is to extract the information, then I would highly recommend using the information extractor that would be very easy to set up.
Yeah, itâs inconsistent, which makes it stranger. I have executions where everything works, and a recent execution where it got divided into two runs .
I changed the LLM node to not retry by itself if it fails (maybe that can cause the split?) and to return errors hopefully similar to when the LLM responds with an error, and just have my logic figure out the retries.
I hope youâre doing well too @Camila
I would test disabling the Retry on Fail on the Message to model node itself, because today you already control the attempts in the workflow; keeping the nodeâs internal retry on can create additional passages and misalign the Merge, especially when using combineByPosition.
I think the issue is that the Merge node is not able to merge items from different runs.
On the second+ run, only one input of the Merge node will be affected.
Ah, that explains it â the Merge node only merges data from the same execution run. In a retry loop, the second time the workflow fires, Input 2 of the Merge node is coming from the ânewâ run, but Input 1 is still waiting for data that will never arrive from the previous run. They arenât running at the same time, so Merge just sits there with one input incomplete.
What barn4k posted is the right approach: ditch the Merge completely and use $(âReduce tokens (lossless)â).last().json to grab the data from the most recent finished run. That way you always have access to the previous state, without trying to merge live streams. The $runIndex trick for the retry limit is also cleaner than keeping your own CURRENT_RETRY counter â you just compare $runIndex to MAX_RETRIES.
So Camila, try importing barn4kâs workflow as-is. The only thing to watch out for: make sure your Message a model node has onError: continueErrorOutput set (not continueRegularOutput), because thatâs what feeds the error branch now. If you have any issues after import, drop the exact error here and weâll get it sorted.
Wow, thatâs so much cleaner, thank you so so much! It seems to be working well now. I didnât know that you could do that with .last(), Iâm gonna do some reading.
Thank you all for your help!!!
Edit: I changed the .last() method to .itemMatching($itemIndex) so it can work if it has multiple items (as is my case, one item per ticket). Otherwise it seemed to grab the same item every time.
.
