Odd error around options.agent when upgrading from 0.222.1 to 0.236.3

[NealSr]

Describe the problem/error/question

I recently upgraded from 0.222.1 to 0.236.3 and everything appeared to go smoothly including our workflows succeeding just fine for about half a day when suddenly we started seeing error messages when one workflow tried to call another webhook (workflow) through an HTTP request.

Now whenever we kickoff a workflow the first workflow will start just fine but the follow-up workflow will never be executed and the first workflow HTTP request will error out with “undefined” and an odd error message.

What is the error message (if any)?

TypeError [ERR_INVALID_ARG_TYPE]: The “options.agent” property must be one of Agent-like Object, undefined, or false. Received an instance of Object.

Please share your workflow

Share the output returned by the last node

Pretty much a JSON response with the above error message. I’ll post a screenshot but I forgot to copy the text unfortunately.

Information on your n8n setup

• n8n version: - 0.236.3
• Database (default: SQLite): SQLite
• n8n EXECUTIONS_PROCESS setting (default: own, main): main
• Running n8n via (Docker, npm, n8n cloud, desktop app): docker-compose
• Operating system: ubuntu

[Jon]

Hey @NealSr,

I suspect we will need more of the data, If we were to run the workflow that has the issue we will see other isses and not the one you have reported. I would maybe start by changing {{ $node["Requested Services"].json["url"] }} to just {{ $json.url }} to see if that helps but I am also not sure what the JSON results of function node 0 query actually is and the issue could be there.

[NealSr]

Thanks for the feedback @Jon -

I updated the json call but it didn’t seem to change anything. As a troubleshooting step, I switched from query parameter to body, and got the same error message. (I’ll past the full output below).

The strange thing is that when n8n first comes up the workflow functions perfectly, but the 2nd run of the workflow is where it errors out (same input).

I did see the note at the bottom of the HTTP node that says:

You can view the raw requests this node makes in your browser’s developer console

Do I need to be in test mode to see that or will it log to the console when I open it from the execution? I’m having trouble figuring that out.

[
  {
    "error": {
      "name": "RequestError",
      "message": "Error: Argument error, options.body.",
      "cause": {},
      "error": {},
      "options": {
        "timeout": 3600000,
        "headers": {
          "accept": "application/json,text/*;q=0.99"
        },
        "method": "POST",
        "uri": "https://n8n1.<domain>.com/webhook/<webhook_name>",
        "gzip": true,
        "rejectUnauthorized": true,
        "body": {
          "act": "<webhook_name>",
          "ws": "<ws_id>",
          "eid": "<eid>",
          "et": "reaction",
          "aid": "<aid>",
          "txt": "u+1f525"
        },
        "json": false,
        "simple": true,
        "resolveWithFullResponse": false,
        "transform2xxOnly": false
      }
    }
  }
]

[NealSr]

One additional piece of troubleshooting:

If I change the HTTP node from sending “$json.req” to individually sending “$json.req.act”, “$json.req.ws” … “$json.req.txt” (all of them individually). it seems to work fine.

[Kent1]

Hello,

I had the same issue when I update to 0.236.1 (no issue with 0.236.0). In the same time splunk node doesn’t work anymore.

I had also others issues with database so i came back to a lower version 0.231.1 and will performe some tests before to update to the new version.

[Jon]

Hey @NealSr,

Sadly without actually seeing the full thing it is very hard to provide an answer, I don’t know what json.req.act is or what json.req is is this an array or the body from the webhook?

If you can provide a more complete example of the function output I can look into this in more detail. It sounds like it could just be a data type issue.

With the message about viewing the request it needs to be in the test mode.

[Jon]

Hey @Kent1,

Do you have a topic open about the Splunk node?

[NealSr]

The issue appears to be intermittent, even with identical input.

I went ahead and created a very simple workflow with only static input from the code function and a simple call to the HTTP Request node. It worked for most of the afternoon, then about 5 minutes ago it suddenly started failing and I could not get it to work again. Then I restarted docker-compose (down and back up) and it’s working again.

Is there any additional data I could pull from an execution that would be helpful?

Initially I thought maybe it was because I was using an old HTTP Request node so I created the workflow below with one of each version (that I could find). All of them worked most of the time except when they crash with the options error.

[Jon]

Hye @NealSr,

Are you actually calling an n8n workflow? It could be that this is related to another issue issue that had a different error presented which should be fixed in 0.237.0 but it feels like this could be somethign else.

Can you share the full error output?

[NealSr]

That’s correct the workflow I posted does some processing to determine what sub-workflow to call. Rather than have all our nodes in a single workflow we essentially do the switch statement with a code node and then call the appropriate sub workflow afterward.

I haven’t seen the error in a little while - I’m not sure why it’s intermittent but it seems to only break when I don’t want it to and works when I want to capture the error.

Note that the other webhook (the sub-workflow) never seems to get triggered so I can’t see what it is actually failing on.

This is the last time I saw an error yesterday.

[Jon]

Do you have an example of one of the other node versions failing?

I need the full stack error that would typically in the output for any errors.

[Kent1]

Hello,

No. I had bigger issue with the database so I focused on this issue before to rollback ! And now I’m still in 0.231.1 si can’t reproduce the issue

[NealSr]

@Jon
thanks again for all the help investigating this.

I have been unable to reproduce the error the last 4 days and so I’m thinking it could have actually been a DNS / networking issue on my end or some other problem that went away after upgrading to 1.1.1

For context I’m hosted on AWS using docker-compose and about a week ago we had to power down the server completely (I forget why) which changed the IP address. I’m wondering if the server went to DNS for our n8n server and failed to resolve it, but leaving a less helpful error message.

If it isn’t that I’m at a loss unfortunately. We’ve upgraded to 1.1.1 and haven’t seen the error that came up on 0.236.3

For my future reference, is there a better way to have one workflow call another workflow’s webhook? Right now we’re using that HTTP request node to do it.

[Jon]

Hey @NealSr,

If the workflow is on the same n8n instance you could use the execute workflow node.