Breaking changes in webhook format after upgrade?

Upgraded yesterday to Vo 1.2.2 and having various issues with workflows.

First one is webhook seems to be returning all values received now always as an array, so most of the code manipulations or conditionals based on these fields now fail.
We reviewed the breaking changes changelog of 1.1.1, but did not see anything mentioning this change.

So pair values that before where received as:

Ds_SignatureVersion:HMAC_SHA256_V1

Now are:

Ds_SignatureVersion
0:HMAC_SHA256_V1

Is this the new behaviour? Is it documented any where together with other possible breaking changes?

Thanks.

Hi @luison :wave: Sorry you’re running into this - what was the last version of n8n you were using before upgrading to 1.2.2 / when the webhooks were still returning the response you’d expect? Is this only happening with key/value pairs you’re sending to the webhook?

I did see a recent change to the responses from the Respond to Webhook node on our release notes, but that doesn’t sound like what you’re running into.

Running as “it used to” in Vo. 0.236.3

We understand we get this on all listening webhooks, not only those values sent. I should clarify this are all POST data being sent.

Just done another test from a simple postman “post” call to both versions to the same workflow and webhook and the same result.

Vo. 0.236.3
image

“body”:
{
“email”:
[email protected]”,
“fist_name”:
“test name”
}

Vo. 1.2.2
image


"body": 
{
"email": 
[
"[email protected]"
],
"fist_name": 
[
"test name"
]
}

So what before was:
if (item.hasOwnProperty('body')) {

now has to become:

if (item.hasOwnProperty('json')) {
  if (item['json'].hasOwnProperty('body')) {

Also affecting Ifs for example:
{{$json["body"]["domain"]}}

now is
{{$json["body"]["domain"][0]}}

Setup of both versions is identical… running on docker, same config.

Hey @luison,

That is perfect, There was another report of this recently and we couldn’t reproduce it and the key part is form-data when that is used it does seem to break it which is not idea. I have raised it internally so this should hopefully be fixed in a future relase. It looks like 1.1 and 1.0 are not impacted so for now I would use one of those releases.

2 Likes

Hey @luison,

This has been fixed in the PR below and will be available in a future release (probably 1.3.1).

1 Like

New version [email protected] got released which includes the GitHub PR 6967.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.