Function Not Found

You are in luck! There is an Open Source version of the Particle cloud server. I can’t say for sure that the code in this version matches the hosted version most people use but since you feel so strongly about this and have a solution I would encourage you to submit a PR with your fix, maybe they will implement it in the hosted version as well. This is a community contributed platform, many people submit bug fixes or tweaks they feel are useful to others so if you aren’t willing to contribute to the fix please be willing to accept the API as it is with a respectful request for improvement in the future.

Let’s all remember the cloud service is free and I am willing to bet represents a significant monthly spend for Particle but that aside you are left with (3) options at this point:

  • Accept it
  • Fix It in OpenSource Spark-Server and submit a PR requesting review/implementation in the cloud version
  • Fix It and run it privately on your own Spark-Server instance

Not many vendors could offer so many wonderful options to a user!


I don’t agree that there’s no way to do it in the cloud. Simply check the length of the function name that comes through. If it’s more than 12 characters, return an error. I can’t believe so much argument is being made about something that’s so very, very simple. If the limit is ever increased, change the limit in the cloud check function and it’s suddenly compatible.

There is no name coming through, since Particle.function() fails to register it!

This was clearly stated by multiple people in several posts.



All I’m trying to do is suggest a way to make this more seamless for developers. I really don’t appreciate the “this is costing Particle money, so you’d better like it or accept it.” I’m trying to help, I’m trying to share my experiences in an effort to make it easier for others to come up to speed on this. Thanks for making me feel like my suggestion is stupid.

1 Like

The function name is on the end of the URL. Not rocket science to look at it, see it’s too long and reply.

You seem to miss the point.

What do you expect your filesystem to tell you, when you ask it to

cd /thisDoesNotExistNoMatterHowLongThisIs

Do you expecti it to return, “This is no allowed directory” or “Not found”?

There might be multiple reasons for the function name not existing, but “Not found” is definetly true, no matter why.
If you want to find out why, go to the root!

If you refer to the URL path, this will be well-formed even with a long function name, but the “path” does just not exist.

1 Like

Okay, for the very last time…

You put a function in your code.

If the function name is <= 12 characters, the device registers it and submits it to the cloud.

If the function name is >12 characters the device doesn’t register the function and it doesn’t get submitted to the cloud.

The cloud can only reach functions it knows of.

It knows of functions because the devices told them what they were.

If the device didn’t tell them a function exists, the cloud doesn’t know the function.

If you call a function from the cloud, the cloud must know said function.

If the cloud doesn’t know a function you’re trying to call, it will tell you so.

The message you get when the cloud doesn’t know a function is “function unknown”.

The cloud is ‘stupid’. If you don’t tell it something exists, it doesn’t know.

The device is the one who tells the cloud what does or doesn’t exist.

The device won’t tell the cloud your function exists if you don’t stick to the rules (<= 12).

Computers don’t make mistakes, humans do.

You CAN NOT check for a function in the cloud if the cloud doesn’t know it exists in the first place. Better yet, it doesn’t exists, because it broke the rules, and was thus not created.

I don’t care WHAT you put on the end of the URL, if it’s not there, you’re not going to find it. On that I must agree, that’s no rocket science if you ask me…

OK, for the very last time…

The cloud COULD check the length of the function it’s being asked to use and, if the length of the function name is more than 12 characters, it would know why it won’t be found and return a more useful response. That’s all I’m trying to say. Who cares how dumb the cloud is? Make it a little bit smarter. It’s still just a few extra lines of code to understand this problem better.

Why are you so opposed to making this more robust?

If it knows it’s too long, it will know it will never find it and can actually HELP the developer deliver a better implementation. All this did was make it harder to figure out what was wrong instead of simply telling me what the actual problem is. The problem is that my function name was too long and therefore wasn’t registered. The indication/indicator is that the function name could not be found. The latter indicator is not a good representation of the former.

I’m now officially sorry I ever even suggested something that would make the product better.

1 Like

I am not missing the point. The folder not found error in DOS is accurate because the folder doesn’t exist. In my case, I made the function, the device ignores it, so it’s not that it’s not found - it’s there, I just used a name that’s too long. That’s a COMPLETELY different problem.

First of all, I’m not opposed to improving anything, let that be clear. I just think this thread has gotten way more confusing than it ever needed to be.

The cloud cannot check for function length on the device, since it has to be the device who tells the cloud what is and isn’t there.

That’s the thing, it ISN’T there, BECAUSE you used a name that’s too long. It doesn’t exist. “Function can’t be found” is therefor a very appropriate response.

If what you’re suggestion is an input check on the API, then yes, that wouldn’t be a bad thing. But there’s a multitude of reasons why a function can’t be found, so you’d have to account for those as well.

Let’s ask @dave to chime in on the possibilities of implementing this on the cloud side, as far as pro-active input checking goes. I’d then also suggest to add a note that mentiones:“you should really consider reading the docs”, but that’s my personal opinion.

Sorry if I gave you the feeling that suggestions are unwanted or that we’re firmly opposed to any such ideas. I think a fair bit of this topic is based on misunderstandings, which I hope won’t interfere with the intention of improving the platform. Suggestions like those are definitely welcome, and I genuinely hope you’ll continue to make them in the future.

Yes you are.
Have a look at your URL and see the resemblence with a filesystem path.
Imagine you have a folder (with some executable in it) on your USB drive and you try to copy (or link) it to your HDD but this copy (or link) fails but you ignored the result of the copy/link action.
Later on you try to execute the supposedly copied/linked program - what would you expect to happen?

That is exactly what happens if your firmware function exposure fails. The endpoint had not come to exist (on the cloud side - which you are talking to)

No I’m not - please stop telling me I’m not understanding something. You have absolutely no way of knowing that. Just because you think I’m not understanding you doesn’t mean that I am. You’re ignoring my point and using what you think you know to say that I’m missing your point. That’s rude, inconsiderate, and disrespectful.

I understand URLs and File systems. I’ve been a professional software developer for more than 30 years and I’ve written 6 books on mobile development. I understand all of this.

I get it, I get the fact that the device never registered the function, therefore the cloud can’t find it. I’ve never, never ever argued that that wasn’t happening. What I’m saying, and you’re COMPLETELY ignoring it, is that there’s a way to tell that the function won’t be there and let the user know.

When DOS delivers a file not found or a folder not found error - it’s because it’s not there. When the Particle cloud delivers a function not found error, it’s not because the function’s not there, the function actually is there - it’s because it wasn’t ever registered. It’s there, it’s just that the cloud can’t see it. Yes, it feels like it’s not there, but to me, as I was toubleshooting this problem myself, it was not a clear error as everything I was seeing told me it was there. That’s why I’m suggesting, and not because I don’t understand something that’s been said here, is that it’s possible, and I’ve shown several ways already, to provide the developer with a more useful error message. Again, I promise you that my stupid little suggestion isn’t coming because I don’t understand you, I do understand what everyone is saying, I simply don’t agree it doesn’t need to be changed.


I get the point @johnwargo is making. Will people please stop trying to talk him out of it.

The cloud knows damn well that if you try and access a function/variable with >12 characters in the name, it’s never going to work. Let’s have it impart that knowledge back to the caller.

All the other points people are making are technically accurate, but miss his central point, which is about making these things less arcane for users who stumble into this problem.


Hi @johnwargo,

Thanks for posting your experiences and feedback, it’s very valuable!

I agree that the error messages and hints you got from the API in this case were probably confusing, and could have been more helpful. As an engineer building tools like this, it’s critical that we accept and internalize feedback, especially when it challenges our assumptions about how something should behave! So, tl;dr; thanks! I agree that we can make the errors more helpful. I plan to bring this up with the team, and talk about how we can improve on our end.

There was a question mentioned, “Why doesn’t the cloud API just tell you a variable over 12 characters would never work?”. I wanted to share some backstory on that in case it’s interesting. :slight_smile:

Your question is awesome, and the answer involves some assumptions I made, and limitations we had on the Core. The Spark Core had 20 KB of ram, about 4K of which was available to user apps. Registering variables and functions impacted that space, and they couldn’t be dynamically reserved like they are now (I hope?). So limiting the length to 12 bytes was a decision that happened in firmware for the Core, but wasn’t a constraint that needed to exist on the cloud.

I figured we wouldn’t have the same hardware limitations forever, and certainly people might make their own hardware, so the cloud didn’t worry about how long functions or variable names were, it would defer to the device itself to set those limitations. The device would be the source of truth. This is really convenient for someone building a giant distributed system, and it’s nice for being flexible, but it can be confusing if you don’t have that knowledge. I’ve also been caught at times by similar assumptions around our security model when I’m trying to call a function only to discover it’s on a device I don’t own, etc, etc. :slight_smile:

Anyway, that’s all to say, thanks again for the awesome feedback, I love when people post stuff like this, and we’ll keep trying to make things better on our end.



Indeed! That a great idea: catch everything you can at compile time. I’ll make a pull request with this.


Dave, implicit limits are totally understandable, especially given the history.

Either enshrine them as absolute known constants or make them dependant on the version/capability of the protocol that is running/negotiated between the cloud and the device. However I don’t think it is certain that resources available on devices will always grow over time, think BLE endpoints etc,

So a fixed value of 12 is not a bad number, IMHO. Remember, some of us cut our teeth on systems where things had to be unique within 7 or 8 characters, and produced non-intuitive compiler messages (admittedly they were compile time errors, not runtime). But kids these days are used to variable names without limit, so if we are going to limit, let’s make it obvious and inviolable.

1 Like

A warning in this situation will be valuable for both beginners and experts. This discussion lead us to figure out that the best place for this warning is in the firmware build process, as opposed to the cloud server or the client (CLI).

The firmware compiler will now generate an error at compile time when a function or variable name is too long. This will be available in the next firmware release.


Just to be clear about this

Which will only work if the length can be assessed at compile time - meaning string literals are used (which will be in most cases ;-))

Woohoo! That’s exactly what’s needed, let them know it won’t work.

1 Like

5 posts were split to a new topic: Discussion about maximum function / variable length