Custom cloud code is disabled for this type?

[Todd]

I have a Backend Services type with some custom cloud code that has been working fine. After making a change to the cloud code, I began getting this error message on all requests:

"message": "Custom cloud code is disabled for this type.",
"errorCode": 955

I undid the change, but the error persists. I even removed all custom cloud code from this type and I get the same error message.

How do I "re-enable" the custom cloud code? (And how did it get disabled in the first place?)

[Anton Dobrev]

Hi Todd,

This message is dispatched when a cloud code for a content type has resulted in too many timeouts for a limited time interval. The execution of this cloud code is disabled automatically by our infrastructure. Unfortunately, this restriction is not documented and we will make sure to update the documentation. Note that the limitation is imposed for timeouts that are intensively recurring within a predefined time interval. Occasional timeouts at the time of developing and debugging will not shut down the cloud code for a content type.

Could you please verify the validity of the registered cloud code in this content type, for instance:

 - The code is registered with respect to the natural order of the cloud code events.
 - The done() handler is invoked everywhere it is needed.
 - Avoid making external calls that may not complete in a timely manner in regard to the cloud code execution limits (5 seconds per event).

Meanwhile, the cloud code execution has been enabled for this content type.

Please, accept our apologies for the inconvenience.

Best regards,

Anton Dobrev
Telerik

 

 

[Todd]

Thanks, Anton.

I assumed this was the case (that Backend Services had automatically disabled the cloud code). While doing some development on new cloud code, I discovered a place where I created an infinite loop (cloud code for Type A requested Type B, and cloud code Type B requested Type A).

While I understand the need for this kind of infrastructure safe guard, I think it is important that the auto-disable either A) expires after a set amount of time, or B) can be manually turned-off by a developer. Without one of those options, apps are broken until support is able to remove the cloud code restriction.

Is there an undocumented API that can be called to change the "cloud code disabled" flag?

Meanwhile, thanks for the help with this specific type! I will try not to re-trigger the limit with my cloud code dev (but I make no guarantees). :)

[Anton Dobrev]

Hi Todd,

I am glad to hear that everything is now working on your side.

You are right that although these measures are taken with the aim to increase the infrastructure's invulnerability, they can cause a lot of frustration for developers that are building a complex cloud code logic. Nevertheless, given the nature of this restriction, no public endpoint is available for enabling a disabled cloud code.

Thank you for your valuable feedback on this matter. I will make sure to pass your suggestions to the engineering team. 

Please, let me know if further questions arise, I will be happy to help.

Best regards,
Anton Dobrev
Telerik

 

 

[Ken]

I am experiencing this same behavior and I am stuck now because I can't access the type at all. What can I do to escalate this so that support will reset this flag quickly?

[Dimitar Dimitrov]

Hi Ken,

We have already answered you in the support ticket that you have opened.

Currently that is the only way to report and resolve that type of issue.

Regards,
Dimitar Dimitrov
Telerik

 

 

[David]

Looks like I may have caused one of my Cloud Functions to be disabled as well. Unfortunately, it's an important one - for signups - and live. I submitted a ticket about an hour ago, but haven't heard anything yet...

[David]

It appears that renaming the disabled cloud function to something new and then creating a new function with the same name as the original disabled one, fixed the issue for me. At least I think that worked.

[Anton Dobrev]

@David

Yes, this should work for you.

We noticed on time your support ticket but I am answering here so that the reply is available to the community. I would like to offer our apologies for any caused inconvenience.

In addition to the post of my colleague Dimitar, I can confirm that we are improving the policy for disabling cloud code for data/functions in terms of recognizing better the reasons for any code that results in timeouts and allowing customers to improve/fix their code before it is recognized as harmful or potentially malicious. The expected result would be that our customers do not encounter such impediments in the future.

Let me know if further questions arise.

Regards,
Anton Dobrev
Telerik

 

 

[Matt]

hi, we're about to go live with an app that uses a lot of cloud functions to access our webservices for data.  it's possible our services go offline for unknown reasons.  obviously, when that happens, the cloud functions would start timing out and possibly get permanently locked.  i'm trying to think of a way to plan for this...

 ideally, we could trap some kind of timeout error in the cloudcode and send an email to our tech guys, maybe even respond back to client app with a graceful failure of somesort and never have the cloud code get locked out.  i thought i'd put a setTimeout in the cloud function for about 9sec (less than the 10sec cloud function timeout) and interrupt manually but...it looks like settimeout isn't supported.  is there another event or process or somethign i can trigger a failure on and maybe react to or do we wait for support calls saying they can't get in and we see our cloud code is disabled?

 

thnx,

Matt

[Matt]

whoops.   i should have mentioned, we're using Everlive.Http.post  commands to our custom webservices.  when our webservices are broken (as they commonly are during development) or the server is down, the everlive.http.post command times out and eventually locks the cloud function.

 

thnx again,

Matt

[Anton Dobrev]

@Matt

Indeed, the performance/availability of external services can lead to too many timeouts of a cloud function and ultimately it could be disabled by the system.

Along with the improvements already listed in this thread which we are considering, we may consider allowing to set a timeout of the request issued from the business logic layer.

A suggestion at the current stage, however, would be to aim to use only available web services during testing and production.

Let me know if you have further questions.

Regards,
Anton Dobrev
Telerik

 

 

[Randy]

I understand why a problematic cloud function would be disabled.

But why is access to the Type (and all data) disabled from all mobile users and administrators!? This is a very punitive action that in my case and I assume most others will bring the whole system down. And, it appears that there is no opportunity within your platform to rectify the problem without logging a support call and waiting. 

[Anton Dobrev]

@Randy,

Indeed, we do understand your concerns. I believe the issue was resolved in the private support thread you submitted.

Let us know should you have further questions or considerations.

Regards,
Anton Dobrev
Telerik