Issue Overview: Name production matching failure in N8N workflows
I built a NodeJS application that uses Steel browser automation (switched from Puppeteer) and containerized it with Docker. The service runs flawlessly when tested independently.
The problem occurs when I call this service through N8N HTTP requests during workflow execution. The first call works fine, but the second call always throws this error:
Name production matching failed
What makes this weird is that the backend service stays online and responsive. I can trigger the node manually using “Execute Node” multiple times without any problems. External HTTP tools like Postman also work perfectly for repeated calls.
The failure only happens when N8N executes the workflow automatically and makes sequential HTTP requests to my service.
Troubleshooting attempts:
Double-checked all request parameters and headers
Inserted delay nodes between HTTP calls (tried 2-15 second delays)
Verified service logs show no backend errors
This seems like an N8N workflow execution issue rather than a problem with my service. Anyone faced similar issues with N8N HTTP nodes failing on subsequent calls during workflow runs?
Sounds like a session management problem with N8N’s workflow execution. I hit something similar when my containerized service couldn’t handle concurrent or back-to-back requests from N8N properly. The difference between manual runs and automated workflows is how N8N handles connection pooling and request context. Try adding a unique request ID header to each HTTP call, or add proper session cleanup to your Steel browser automation code. Also check if your Docker container has resource limits - that might make the second request act differently under N8N vs standalone testing.
This looks like N8N’s internal caching or state management acting up. When N8N runs workflows automatically, it keeps internal state between nodes that can mess with your HTTP calls - even though your service works fine when tested directly. I’ve hit something similar where N8N was reusing connection contexts wrong. Try turning on “Always Output Data” in your HTTP node settings and see if you’ve got any workflow variables sticking around between calls. What worked for me was splitting the HTTP calls into separate branches using IF nodes - forces N8N to treat each request as independent. Since manual execution works fine, it’s definitely N8N’s automatic execution context causing the problem.
i had a similar issue with n8n too. adding unique query params like timestamps helped sort things out for me. also, make sure that your Steel browser is properly closing sessions between those requests, or you might still run into hiccups!