You can try using an Output Parser tool or Auto Fixing Output parser tool that would work.
Although if chat trigger is not working after all that work, what i would recommend is that to give you like a bit close to chat trigger is that create a website with a chat interface any AI can code that and then let it call that AI webhook and display the data what AI has responded like just a suggestion as we have almost tried everything, and also we can also be crazy by using Trigger as a Form and End Form after the AI Agent to display the output, like crazy stuff if chat trigger is not working.
Yeah, have tried the web form which was ok but no returned info with format.
I have a small ‘vibe coded‘ js app which calls a webhook fine sending the request but the respond webhook node is a real pain with the formatted text being sent back (invalid json format). It is usually /n needing to be escaped to //r and ‘\’ in dates needing escaping etc.
The problem is that when the respond webhook mapps the text to it’s input json format, it removes the \n’s that a prior node has escaped with regex, leaving only a ‘\’ which is invalid. If, however, I do not escape the \n, the respond webhook does not remove them and then the json format fails as being invalid for having \n… It is infuriating.
Trying with cut down random text (1,000 characters) including both the \n and ‘/’, it works fine. Seems to be something to do with the amount of text but the amount is well under the 16mb limit with Ai Agent output being around 4,000 characters..
@Rimblock Have you tried using code node to solve this problem? Although that would still be to an extend, but if the workflow start is something then you can try using Webhook trigger and the continue the flow without respond the webhook. Let me know what you would pick.
Yep, I have a test harness app, (in js) and a basic workflow that receives the webhook request, uses a set node to set a result variable with a test output (usually from the other workflows Ai Output copied over), runs the regex on it and pushes it to the respond output.
Fairly easy to spin up and test Ai results without running the agent, and test the regex.
One big issue is that the model (GLM-4.7-flash) loves to give me all the thinking text… pages of it. Due to this I have a system prompt telling it to put the result in a flat json kv object called result. This generally works and so the regex escapes the sensitive characters etc, pulls out the json structure from the Ai output and trashes the rest. It then passes it on to the respond webhook.
The regex is very precise though so changing the text can cause the identifying regex to fail, Ai Output is slightly different and the regex can fail, then if it is ok, the repond webhook usually fails due to invalid JSON object.
Code node js.
const text = $input.first().json.output; // Ensure 'output' is the correct field name
// 1. Remove Markdown code blocks
const cleanText = text.replace(/```json\n?/g, '').replace(/```\n?/g, '');
// 2. Normalize line endings
const normalizedText = cleanText.replace(/\r\n/g, '\\n').replace(/\r/g, '\\n');
// 3. Apply your regex
const regex = /(\{([\s\S]*?)\})(?:[\s\S]*?)/s;
const match = normalizedText.match(regex);
return {match}
if (match) {
// 4. Parse and Clean the captured JSON
try {
let resultStr = match[0];
return { json: JSON.parse(resultStr) };
} catch (e) {
return { json: { error: "JSON Parse Error: " + e.message } };
}
} else {
return { json: { error: "Regex did not match" } };
}
I have been considering converting it to unicode but then its 4 times the number of characters. I could convert to ascii with a seperator, but again that bloats out the data being sent back.
This just feels far too much work for something that should be super easy ¯\_(ツ)_/¯.
Formatted text from an Ai Agent –> User retaining the format (using only local tools).
Ok, last ditch effort… tried a completely clean install. New persistent storage ert and built the workflow from scratch (rather than loading from a saved copy).
The good…
The model and context does not blow my GPU VRam resulting in workflow running for around 1:30 mins rather than 29 mins when it drops to CPU. This is what used to happen, not sure why it changed.
The workflow run took under 1:30 min.
The bad…
After adding more nodes, specifically to push the workflow over 1:30 min, I get the same timeout issue.
I suspect the upgrade from n8n v1 –> v2 resulted in issue with node versions. Saving and loading workflows brought v1 nodes into the v2 environment and testing back and forth between n8n version was causing some static.
Final result, chat trigger times out after 1:30 mins.
Hi @Rimblock let me give you a point, what i have observed is that when you add your chat trigger as a:
so when you made the workflow available in chat hub and then also make sure your chat trigger’s output properly settled up on AI agent or anything and then once that is done publish your workflow and now goto chat hub select workflows drop down and there choose that chat trigger flow and when you will send messages from there i mean Chat Hub that would work and would make the workflow execute as it does. Hope this brings some help.
for @Rimblock and others on Docker + queue mode — the Chat Hub suggestion works for cloud/simple setups but doesn’t fix the root cause on self-hosted queue mode.
the “Waiting for you to submit the chat” + “Failed to receive response” pattern on Docker with Redis is almost always one of two things:
1. n8n-runners not connected to the same Redis instance — the main n8n process receives the chat message but the runner that processes it can’t pick up the job. check that QUEUE_BULL_REDIS_HOST is identical in both your n8n and n8n-runners containers. a common mistake is one pointing to localhost and the other to the Redis container name.
2. N8N_RUNNERS_ENABLED not set — if you upgraded recently and this env var isn’t explicitly set to true in your docker-compose, queue mode can silently fall back to a broken hybrid state with the new runner architecture. add it explicitly and restart.
quick check: run docker logs n8n-runners right after sending a chat message — if you see nothing, the runner isn’t receiving jobs at all, which confirms the Redis connection issue.
Thank you Rimblock for putting in so much effort to troubleshoot this issue. I’m getting the same thing, and setting N8N_RUNNERS_ENABLED=TRUE hasn’t fixed it. I’m running via nginx proxy.
Thanks, I have not looked in to the CHat Hub yet. Will take a look later.
@Pavel_Kuzko , You are correct and this was the initial problem with the chat displaying the ‘Waiting for user input‘ message.
Sorting out the runners communication as documented at the beginning of this thread, did move things forwards. Unfortunately it did not resolve the ‘Gateway timeout‘ issue.
One other thing is that the workflow runs and completes with the last node having an output that I would expect. It is the chat triggers ability to receive and display the last nodes output that times out.
@DandaIf : No problem. Glad this will hopefully help others.
It is worth noting that if you have the chat trigger and add the ‘Response mode‘ option, setting it to “Use response node‘, you can then add a chat response node later (at the end) of the workflow and it wont timeout (or doesn’t for me). It is only using a chat trigger without setting the response mode option that seems to cause the gateway timeout.
@Jes6ka_W : Thanks for sharing. Unfortunately it has not resolved the issue for me. Still getting the 504 gateway timeout message after 1 minute 30 seconds.
I was headbanging with same issue and it turned out the problem was not the same:
”Failed to start Python task runner in internal mode. because Python 3 is missing from this system. Launching a Python runner in internal mode is intended only for debugging and is not recommended for production. Users are encouraged to deploy in external mode. See: Task runners | n8n Docs
I’m leaving this for others having same issues as I did, the solution was adding n8n-runners to my compose and setting N8N_RUNNERS_MODE=external, now everything is working fine.
@Jes6ka_W your suggestion saved my day! Tried to use stable image version first, then I tried to set up external task runners according to docs, but what was really missing was the N8N_EDITOR_BASE_URL env variable. If anyone face the same issue, try this first.
