ST's ghost Routines, returning null labels and groovy not executing spread operator correctly

@Aaron @slagle this is an offshoot of the problem folks are reporting here:

So with @elekktronix help I isolated the data being returned by ST and for some reason ST is returning “null” for the labels for some routines. Running this code:

location.helloHome?.getPhrases()

returns:

[[id:77d14c8d-072b-4b6f-a74b-d40895899799, label:Set Mode Home, hasSecureActions:false, action:/api/smartapps/installations/77d14c8d-072b-4b6f-a74b-d40895899799/action/execute], [id:0ce15648-afa4-4e68-a63c-6ba9263be934, label:Set Mode Morning, hasSecureActions:false, action:/api/smartapps/installations/0ce15648-afa4-4e68-a63c-6ba9263be934/action/execute], [id:01b6fa49-5e0c-4aed-aa3d-c3856f0fe4ed, label:Good Morning!, hasSecureActions:false, action:/api/smartapps/installations/01b6fa49-5e0c-4aed-aa3d-c3856f0fe4ed/action/execute], [id:f839ddab-184f-4ffd-b772-74cd3b8b1256, label:Goodbye!, hasSecureActions:false, action:/api/smartapps/installations/f839ddab-184f-4ffd-b772-74cd3b8b1256/action/execute], [id:734a1810-f146-4d61-9b7b-254a066fe263, label:Everyone Gone, hasSecureActions:false, action:/api/smartapps/installations/734a1810-f146-4d61-9b7b-254a066fe263/action/execute], [id:af4e610c-7a37-4b8b-9aeb-f08318d15220, label:null, hasSecureActions:false, action:/api/smartapps/installations/af4e610c-7a37-4b8b-9aeb-f08318d15220/action/execute], [id:27cba721-07cd-496c-87e0-755c2630abd6, label:Good Night!, hasSecureActions:false, action:/api/smartapps/installations/27cba721-07cd-496c-87e0-755c2630abd6/action/execute], [id:3c90aba9-f525-439a-bd98-51d4acc093f1, label:I’m Home!, hasSecureActions:true, action:/api/smartapps/installations/3c90aba9-f525-439a-bd98-51d4acc093f1/action/execute], [id:0c37bb61-3bdd-4599-b6c1-6fad2e890ecb, label:Set Mode Away, hasSecureActions:false, action:/api/smartapps/installations/0c37bb61-3bdd-4599-b6c1-6fad2e890ecb/action/execute], [id:bfea7124-ddff-4d77-91fa-175e958c990d, label:Night Time Lights Off, hasSecureActions:true, action:/api/smartapps/installations/bfea7124-ddff-4d77-91fa-175e958c990d/action/execute]]

Did you notice:

[id:af4e610c-7a37-4b8b-9aeb-f08318d15220, label:null, hasSecureActions:false, action:/api/smartapps/installations/af4e610c-7a37-4b8b-9aeb-f08318d15220/action/execute]

Why is ST returning ‘null’ for a routine label? This is ghost routine. Folks have been reporting this since last week.

This brings me to a second issue, on the above if I use:

location.helloHome?.getPhrases()*.label?.sort()

The platform throws an error. Why? The spread operator is supposed to take care of null instances so why isn’t groovy in ST handling this? I tested this code on another groovy platform and it works fine there.

Request your attention to this as it’s impacting more folks each day.

1 Like

I recently had to trap this in my own community developed app. However, this Null routine happens (typically) when you start to create a routine and then abandon it by killing the ST app. This is in complete control of the end user…to delete these (they will no longer show up in the app when they are ‘null’) you will need to get into the IDE, identify the routine that is null, and manually delete it.

I am not sure what you are seeing is on ST’s side of the house except to allow null routines in the first place.

1 Like

Exactly, why allow creation of null routines? I’m sure ST can check for it. Also the folks can’t seem to delete it from the IDE also, they need to contact support in some cases.

Second, why is the .* operator throwing an error. The code above is the "recommended’ code for ST’s documentation, it should work.

1 Like

To be fair, you will get an error if you run into a null in a case like this:

if (device.size()>1) …

You have to ensure that the object is actually not null:

if (device && device.size()>1)…

I am by no means an ST apologist, and your point that a routine is allowed to be null is certainly a problem; however in the absence of ST fixing that an app should trap that condition. That is my only point…

As for deleting it from the IDE, I have never heard of anyone NOT being able to delete a null routine unless it was previously used somewhere, ended up being null somehow, and then being unable to delete it because it isn’t visible in the app…However, in most cases I have seen null routines simple from the ST app crashing in the middle of creating a new routine.

1 Like

Not sure how many more null safe operators I can put into a single statement:

location.helloHome?.getPhrases()*.label?.sort()

The platform isn’t handling this correctly and is throwing an error, hence my question to the ST team.

1 Like

Ticket created.

1 Like

Thanks but for which issue?

Can I assume ST will fix getPhrases() so that it won’t return a ‘null’ label? How long for this fix or do we need to go in and put a workaround/patch for each app manually? (not a popular option).

I have no idea if this applies in anyway, but I did want to mention that there was recently a known problem just with the built-in features where people had null routines and something weird about modes and the fix was that they had to create a new mode which somehow cleaned up the mode table and in some cases they had to create a new routine.

Again, I don’t know if it applies, but it was recent and it had to do with no labels on modes and I think routines, so I just thought I’d mention it.

1 Like

BTW, we’ve added a new “first reports” page to the known issues section of the community – created wiki. It’s intended just for a quick description and a link back to a forum discussion topic. There’s a separate section for developer-reported problems with the SmartThings groovy implementation. So it should be a fast place to check and see if anyone else has reported a similar problem recently. First Reports are filed by month. :sunglasses:

http://thingsthataresmart.wiki/index.php?title=Bug:_First_Reports

1 Like

Honest I’m getting tired of putting workarounds for everything…
but this is a great way to track regression, you’re doing what I requested @alex to do last year :slight_smile: great work!

4 Likes

FWIW, there is a fix for this issue that is in our master branch of the affected service :grin:. To provide some context it was following the Child - Parent SA flow where it was getting all routines whether they were completed or not. This functionality has been change to only give completed SAs. There was some discussion surrounding whether or not getting the uncompleted SAs along with the completed SAs should be expected behavior.

1 Like