Issue Summary: Name production matching error during N8N workflow runs
I’ve created a NodeJS application using Steel for browser automation instead of Puppeteer, and I’ve packaged it up in Docker successfully. When run by itself, everything works great.
However, the issue arises when I make HTTP requests to this service using N8N. The first request goes through without a hitch, but the second call during the same workflow consistently crashes.
Error Details:
Name production matching failed during execution
Interestingly, my service stays active and can handle requests. I can manually trigger the node using the “Execute Node” option multiple times without failures, and even external clients like Postman can send repeated requests without any issues.
The problem only appears when executing multiple HTTP requests simultaneously in an N8N workflow.
Troubleshooting Steps Taken:
Reviewed all request parameters and data thoroughly
Added Wait nodes between the HTTP requests (delays ranging from 2 to 15 seconds)
Checked the service logs, which show no errors
It seems that there is an issue with how N8N processes sequential HTTP requests while executing workflows. Has anyone else had similar problems with N8N?
I had a similar issue with multiple HTTP requests in N8N, just with a different service. Turns out it wasn’t the target service - it was N8N’s concurrent execution handling. My workflow was trying to process multiple HTTP nodes at once, which created conflicts even though the service handled individual requests fine. I fixed it by switching the workflow execution settings from parallel to sequential mode. You should also check if your Steel service handles concurrent connections properly, or if there’s some session management issue that only shows up when requests come from the same N8N workflow. Since manual execution and external clients work fine, it’s probably N8N’s internal request handling causing the problem.
This sounds like a race condition or resource contention issue when N8N hits your NodeJS service with rapid requests. Your service handles individual requests fine, but N8N’s timing or connection patterns are probably exposing threading issues in Steel.
I ran into something similar migrating from Puppeteer - turns out my service wasn’t properly isolating browser instances between requests. Since Steel handles browser automation, check if you’re reusing browser contexts or sharing state between requests.
You might need to implement proper request queuing or make sure each HTTP call gets its own isolated browser session. The fact that external clients work fine suggests N8N’s request headers or connection handling is triggering this specific condition.