No HTTP 404 when Core not connected

Troubleshooting
1

For the Cloud API, I am expecting an HTTP 404 response when my Core is Off Line for any API calls. I am not seeing this behavior. Instead, I am getting an HTTP 408 response with:

{
  "error": "Timed out."
}

I got this first thing in the morning when my Core had been offline all night and during the day when I take it off line to test. When my core is online, the same HTTP Request returns the expected JSON object with an HTTP 200.

Help Appreciated! Thanks!

2

Well, the endpoint is still there, a 404 isn’t appropriate. The API URL doesn’t go away when the core is offline, and I think that is the correct behavior.

There is a firmware API you can write into your code to sleep, and that shuts down the Wi-Fi on the Core. At some point, I’m sure that you’ll be able to queue messages to the Core, and you don’t want the API endpoint to go away every time the Core goes offline to sleep.

3

I am basing this question on the Error Codes documented in the Cloud API. If this needs to be updated then great, I will do a pull on the docs. But I think the core question here is that there is no way to know if the core is online. If I call a cloud function and it takes too long to return… how do I know the timeout error is because it took too long or was offline. Sounds like I need to guess at the moment. This is my real issue / question.

4

You are correct, I apologize.

The docs would need updating I think, or the Cloud API itself. They don’t jive, I agree.

Sorry about that.

I suppose some input from an ‘elite’ member would be in order here, preferably @zachary I think, since the code is kind of his deal, I believe.

The code properly returning 404 or 408 would be the ideal fix, rather than just hacking up the docs to match reality. The code should reflect the actual status of the device, if at all possible.

5

Hi @cloris

I think you can first use the devices end-point and then try the function. For an end-point like:

 curl https://api.spark.io/v1/devices/abcdef9876543210?access_token=01234567890

I get:

{
  "id": "abcedf9876543210",
  "name": "myName",
  "connected": false,
  "variables": null,
  "functions": null,
  "cc3000_patch_version": "1.28"
}

So if you first query the device end-point and look at connected true or false, you then should be able to know. When your device is online, you get connected true and a last_heard timestamp field as well.

This is the area of @Dave (or he can direct you to someone) for the doc issue. I know they rolled out some API changes and this might have been unintentional or not.

1 Like
6

@bko - Thanks as always! I like the working option you described. I will have to add a call to my APIs constructor to check of the core is online via your suggestion. I can then manually raise the exception.

Thinking a little more, I hate to think I will have to make this ‘check online’ call prior to making calls to access function or variables. Otherwise, the non-specific ‘timeout’ error will will raise and blind the caller to why it timed out - true timeout or core offline.

@naikrovek No worries. I appreciated your point of view on the endpoint.

Awaiting more input!

7

Hey all,

Good questions! @Dave here, I’ve been writing and maintaining the API.

tl;dr; we’re gonna eliminate the function call timeout when your core is offline, that should be faster. :slight_smile:

Here’s what happens at the moment:

When you call a function on a core, the cloud:

  • Checks to see if you have permission to do that, if not you get a 403 “Permission denied”

  • The function call doesn’t try to ping your core to make sure it’s online, it just tries to call the function on your core right away. (It will timeout after 30 seconds)

  • If your core was online and didn’t have that function, you’ll see a 404 (for function not found), since you’re hitting a function specific endpoint. If there was another error, you’ll get a 400 or 500 depending on what went wrong

  • If it succeeds, you’ll get a 200/OK / { id, name, last_app, connected, return_value }

  • If it times out you’ll get a 200/OK / { ok: false, error } response

I hope that helps! Reviewing some git blame reports, I think it’s been this way for a while, and I’m definitely open to improving this for future versions of the API. My initial priority is eliminating the timeout when your core isn’t online, because I think that’s less than ideal.

Thanks,
David

1 Like
8

You could also use this (without the coreID)

https://api.spark.io/v1/devices?access_token=ACCESS_TOKEN

to get an overview of the statuses of all your Cores.
Instead of trying that before each call, you could try to call your function. When you get a time-out, you could call this method to check for the cause. Just an idea though.

1 Like
9

@Dave, that would be awesome. Will it throw a 404?

As I am working my way through my unit tests, I also discovered that the same issue exists when I call a non-existent variable or function. I am getting a timeout error instead of an HTTP 400. Is this the same issue?

1 Like