Encountering an odd error with options.agent after upgrading from 0.222.1 to 0.236.3

Hey,

I suspect we'll need more data. If we were to run the workflow with the issue, we'd encounter other problems, not the one you've reported. I'd suggest trying to change {{ $node["Requested Services"].json["url"] }} to {{ $json.url }} to see if that resolves the problem. However, I'm also unsure about the JSON results of function node 0 query, and the issue might stem from there.

Thanks for the feedback.

I updated the JSON call, but it didn't seem to make any difference. As a troubleshooting step, I switched from using a query parameter to the body, and I received the same error message. (I'll paste the full output below).

The peculiar thing is that when callin.io first starts up, the workflow functions perfectly. However, the second run of the workflow is when it errors out, even with the same input.

I did notice the note at the bottom of the HTTP node that states:

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 finding it difficult to determine this.

[
  {
    "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
      }
    }
  }
]

One additional troubleshooting step:

If I modify the HTTP node to send individual fields like $json.req.act, $json.req.ws, $json.req.txt instead of the entire $json.req, it appears to function correctly.

Hello,

I encountered a similar problem after updating to version 0.236.1 (no issues were present in 0.236.0). Concurrently, the Splunk node stopped functioning.

I also experienced other database-related issues, which led me to revert to an earlier version, 0.231.1. I plan to conduct some tests before proceeding with an update to the latest version.

Hello,

Unfortunately, without viewing the complete setup, it's challenging to offer a precise solution. I'm unsure about json.req.act or json.req – is this an array, or is it the body received from the webhook?

If you could share a more comprehensive example of the function's output, I'd be happy to investigate further. It's possible this is simply a data type mismatch.

Regarding the message about viewing the request, this functionality is available in test mode.

Hello,

Do you have a topic open regarding the Splunk node?

The problem seems to be intermittent, even with identical inputs.

I've set up a very basic workflow that only uses static input from the code function and a simple call to the HTTP Request node. It worked for most of the afternoon, but about 5 minutes ago it suddenly started failing, and I couldn't get it to work again. After restarting docker-compose (down and then back up), it started working again.

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

Initially, I suspected it might be due to using an older HTTP Request node. Therefore, I created the workflow below using one of each version I could find. All of them worked most of the time, except when they crashed with the options error.

Hi,

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

Can you share the full error output?

Please provide the full error output.

That's right, the workflow I shared performs some processing to decide which sub-workflow to invoke. Instead of keeping all our nodes within a single workflow, we essentially implement a switch statement using a code node and then call the relevant sub-workflow.

I haven't encountered the error recently; I'm unsure why it's intermittent, but it seems to fail only when I don't want it to and works when I intend to capture the error.

It's worth noting that the other webhook (the sub-workflow) never appears to be triggered, so I can't see where the failure is actually occurring.

This is the last instance of an error I observed yesterday.

Could you share an instance where one of the alternative node versions encountered an issue?

I require the complete stack trace, which usually appears in the output when errors occur.

Please furnish the full stack error.

Hello,

No. I encountered a more significant database issue, so I prioritized resolving that before attempting a rollback. Currently, I'm still on version 0.231.1, which means I cannot reproduce the problem you're describing.

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 callin.io 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.

Hey,

If the workflow is on the same callin.io instance, you could use the execute workflow node.

This thread was automatically closed 90 days following the last response. New replies are no longer permitted.