Problem with errorResponseTopic

Cloud
1

Hi there!

I'm having problems understanding how to properly use errorResponseTopic.

Currently I'm running responseTopics without any issue, handling the successful responses flawlessly. But now I also need to handle the errors returning from our server, which would in the console look like this:

Webhook trouble 2.png1773Ă—171 21 KB

My json file looks like the following:

{
"event": "errorClicks",
"url": "our_url_here",
"requestType": "POST",
"headers":{"content-type": "application/json","accept": "application/json"},
"body":"{lots_of_data_here}",
"responseTopic": "hook-response/errorClicks_{{group_belonging}}",
"responseTemplate": "filtered_data_Here",
"errorResponseTopic": "hook-error/errorClicks_{{group_belonging}}",
"mydevices": true,
"noDefaults": true
}

Furthermore, my subscription looks like this:

Particle.subscribe(String("hook-response/errorClicks_" + group_belonging), OKResponseHandler, MY_DEVICES);
Particle.subscribe(String("hook-error/errorClicks_" + group_belonging), errorResponseHandler, MY_DEVICES);

So I can successfully subscribe to the first, getting data fed into the relevant devices, but not the errors! The noticeable difference is whenever I get a successful response, the Particle Console shows

"hook-response/errorClicks_GROUP"

and if unsuccessful

"hook-error/errorClicks/0"

I would have guessed it would instead look like:

"hook-error/errorClicks_GROUP"

Where am I going wrong here?

Thanks! :slight_smile:

2

How are the error responses created?
Since it would be up to the remote server/device to populate the {{group_belonging}} field a non-success event which didn’t actually get created by the remote server/device (due to said error) the field wouldn’t be populated.

3

Ah, of course @ScruffR, thanks for clearing that up. What if I wanted only the device sending the data to receive eventual errors?

I tried changing to

"errorResponseTopic": "hook-error/errorClicks_{{SPARK_CORE_ID}}",

and

Particle.subscribe(String("hook-error/errorClicks_" + System.deviceID()), ErrorResponseHandler, MY_DEVICES);

But I still get the "hook-error/errorClicks/0" reponse. As far as I understood SPARK_CORE_ID is populated by the cloud and not by the server, right? And then should be populated in the response

4

It is populated by the cloud after it got the ID told by the sending device, but again, no sending device, no ID to populate.
AFAIK the two parts of webhook communication flow are not actually linked, so no data from the triggering publish will carry over to the receiving subscribe unless the remote server/device actually relays it - which again won’t happen in an error condition.

But since this seems to be something numerous people would like to see we could ping @will to ask if such a feature was at all thinkable.

5

Interesting! I will circulate within the engineering team as feedback, and let you know if there are any thoughts on how we could support that as a feature.

6

The feedback from the team was that

"errorResponseTopic": "hook-error/errorClicks_{{SPARK_CORE_ID}}", should work. Can you try creating a new webhook and let us know if you still see the same problem?

7

That would definetly be appreciated :+1:
A way to pass “any” data from the calling event into the response irrespective of the fact whether the remote end answers or not - without the need for the remote end to relay the respective “loop-back” fields - would be received well.

8

@will I just tried creating the same webhook with the suggested errorResponseTopic, without any success. Same thing as the above described problem, where the response in the log reads

hook-error/errorClicks/0

9

Thanks for the update. Will update our team internally and come back with another suggestion or fix.

1 Like
10

Any update on this @will ? :slight_smile:

Update:
I now noticed that the line “errorResponseTopic” wasn’t present when I tried to edit the webhook in the console. When I then added "hook-error/errorClicks_{{SPARK_CORE_ID}}" in errorResponseTopic by editing the webhook, it works :smiley:

So there might be a bug when you try to create a webhook through the CLI as I did? Even though the CLI is happy to create it. The .json file looks like this

{
"event": "errorClicks",
"url": "our_url_here",
"requestType": "POST",
"headers":{"content-type": "application/json","accept": "application/json"},
"body":"{lots_of_data_here}",
"responseTopic": "hook-response/errorClicks_{{group_belonging}}",
"responseTemplate": "filtered_data_Here",
"errorResponseTopic": "hook-error/errorClicks_{{SPARK_CORE_ID}}",
"mydevices": true,
"noDefaults": true
}
11

Thanks for the feedback and the ping. I didn’t find anything new on the Cloud side, so agreed that the CLI may be the culprit. I’ve created the following GitHub issue for the CLI:

At this point, I’ll pull @jvanier and @mdma into the thread who can help to verify the issue.

1 Like
12

This is actually a bug in our API ignoring the errorResponseTopic on webhook creation. I opened an internal ticket to fix this in the API. No changes will be needed in the CLI once the API fix is deployed.