Is there any way to get the HTTP response code (e.g. 200, 403, etc.) from a connector call?
Hey @wz2b -
Unless the error is passed in the response body, I donât know if a way to access this status in a connector.
I will write a feature request for this, because it feels like a gap right now and see what I can do to get it prioritized, because I canât think of a scalable workaround.
Pete
Yeah. I support the idea of adding this because error handling is one of my concerns with connectors. Generally speaking, if a connector fails you get a pop-up at the bottom of the screen that tells you that it failed. It is transient (you get about 3 seconds to notice it, or itâs gone). And of course the request doesnât get queued in any way.
What I envision (from the perspective of a software developer) is that if I knew I got a non-2XX response back I might take this request and stash it in a table - a âdead letter queueâ of sorts - to deal with it later. I havenât totally worked out how I want to do this yet. But, without a status, what Iâm doing temporarily is resetting the output variable before the request, make the request, and if the output variable is still empty then I know the request for some reason didnât work.
So in terms of priority, I agree with you this seems important ⌠but I do have a work-around for now, I just donât particularly love it.
Totally makes sense. In my opinion just throwing an error message is inadequate when it comes to error catching in a process critical application.
There has been some discussion in the past to enable on-error triggers that run if a specific trigger fails. We have avoided going down that road, and have instead focused on the changes to make it easier to see if something will fail, why, and how to resolve those potential failure modes (development mode was the first stab at this).
Keep the great ideas coming. Impressed almost daily with the different blindspots you point out.
Pete
Thanks!
A trigger on failure is something I hadnât thought about. That trigger would be on the Step, or the App, or the Connector? I think it would have to be a trigger specifically associated with that specific invocation.
Iâm having trouble visualizing how that would work. Without knowing exactly how connectors are called (under the hood, the fetch() is probably asynchronous) I guess a trigger makes more logical sense, but I think itâs a little trickier to deal with. Iâm thinking maybe it makes more sense to use a variable. Connectors already let you have outputs based on
- Response Body
- Response Header
- Cookie
so I think my inclination here is forget triggers and just add a 4th and 5th one for
- HTTP Response Code (definitely need this)
- HTTP Response Status Text (maybe need this)
That last part isnât well thought-out but what Iâm getting at is itâs perfectly normal in REST land to return application/json on 200 or 201 but return text/plain with a text message on some of the other response codes ⌠the HTTP spec actually says which response codes are allowed to return content and which arenât.
I donât know. Letâs keep noodling this.
I would like to talk about the end game, though. Iâm working with customers who want external systems to be their system of record, so theyâre using connectors to store pretty much everything. I generally advise against this - my preference is to have everything recorded to a tulip table, then synchronize it offboard. In most cases I sync on a timer (polling) but use connectors to signal âThereâs something new, sync now.â
The structure of the outputs is also different depending on the response code. Different outputs structure by response code will be helpful
I just looped in our product manager for connectivity @Sagar. This is incredibly useful feedback for the work his team is doing around connectors.
Keep this amazing feedback coming!
Pete
I donât want to beat this to death but I looked to see if thereâs some standard way of dealing with this in the HTTP spec:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html
and it is described in section â6.1.1 Status Code and Reason Phraseâ. So thinking through that, where you can now select if you want to extract data from a header, a body, or cookies, I think the thing to do here is to add a fourth choice that gives you the status code and maybe a separate way to get the âreasonâ which is usually more human-readable. For me the numeric code is really whatâs important.
There is one other thing though and itâs the main reason Iâm commenting further: keep in mind that an âOKâ status can be anything from 200 to 299 ⌠so a âgoodâ response might be a 200, might be a 201, might be anything else in that 200-299 range (in theory at least). So it MIGHT not be a bad idea for you to also return a âboolâ indicating success i.e. the response code is between 200 and 299 inclusive. That would make it so you donât have to do a numeric range comparison in tulip.
Hey All-
In r246/LTS10 (actively being released this week) the HTTP response code can now be mapped as an output from any connector function:
Pete
6 Likes
most excellent news!
3 Likes
when i run a test with the Status and Code as an output, should it show up in the output window (right) or only when I run the connector function in an app?
Pete, I only just saw this now (sorry, have been off doing other things) but wanted to acknowledge it and send my appreciation, this opens up a lot of options for me. The main one is being able to create a âdead letter queueâ of pushes - if an HTTP post fails, I can just mark it as ânot pushedâ and make it try again later.
1 Like
Hey @jjj -
You should be able to see the response status both in the status tab on the right side, and you should be able to map it to an int (for response code) or text (for message) output.
Pete
I did add them but iâm not seeing them in the output tab. and when I run that connector function in Test, Iâm getting an error that it failed.
@Pete_Hartnett @John Any idea what my problem here might be? I just tried again with the same result. I even clicked the âAdd to outputâ from the Status screen, but not showing up in my output.
Unfortunately I experience the same issue⌠I was sure it used to work, but now Iâm not 100% sure anymoreâŚ
Pete messaged me separately on this issue. What version is your connector host? My issue is that Iâm using EdgeMC as a connector host and this issue should be resolved on the next Edge firmware release.
Jordan beat me to follow up here-
This is a gap that we donât expose well right now, but are moving to do better going forward. What was going on in Jordanâs case is he was using the embedded connector host on his EdgeMC. The last release of the operating system for those devices included the r245.2 version of connector host. Support for mapping to the response code was implemented in r246. This meant the website would allow mapping to the response, but the response would never include this data. With OS56 we will be updating connector host to the r262 (LTS11) version of connector host.
We recently added a mechanism to communicate what functionality a connector host has, and now as we add more functionality, we will only enable it on the website if the connector host supports it. This was first implemented for MQTT support, but there is more we can do to make it clear why a connector host cannot support that functionality.
We are actively building some exciting connector functionality that will require some Connector Host changes, and we will make it more clear what is going on in cases where functionality is tied to a specific version of connector host -
Pete