runIn with overwrite option suddenly throwing errors

General Discussion
1

@Jim has there been any change to runIn today?

This code suddenly stopped working:

runIn(60, deferredRefresh, overwrite: true)

Now it throws this error

error groovy.lang.MissingMethodException: No signature of method: script14732895981372101701857.runIn() is applicable for argument types: (java.util.LinkedHashMap, java.lang.Integer, java.lang.String) values: [[overwrite:true], 60, deferredRefresh]
Possible solutions: run(), runIn(java.lang.Object, java.lang.Object), runIn(java.lang.Object, java.lang.Object, java.util.Map), url(), now(), dump() @ line 374

According to the docs this is still a supported parameter and was working till this morning without an issue. If this has changed, it will break a LOT of existing apps.

2

@Jim @slagle can someone please look into this, it’s causing a lot of apps to break and pretty soon I’ll start getting complaints from users about apps not working and door not locking or codes not working.

3

Sent this up the chain. Will report back when I hear something

1 Like
4

Just tried this and it still seems to work. The stack trace doesn’t match the code that was posted - looks like the parameters may be out of order. The stack trace has:

(java.util.LinkedHashMap, java.lang.Integer, java.lang.String) values: [[overwrite:true], 60, deferredRefresh]

But the contract is Object, Object, Map (Integer, Closure, Map) in this case

See: https://gist.github.com/vl4ds/f9b3ca56c68350c8cc6d76f14a8bf3ed
Which produces:

0fb8dd74-606a-4bc1-ab19-77a00b2b2fc8 9:25:04 PM: info I ran
0fb8dd74-606a-4bc1-ab19-77a00b2b2fc8 9:24:01 PM: info executed runin

Let me know if I misunderstood your post -

1 Like
5

You got it right @vlad and I couldn’t understand it either hence my post, posting the code and error just as I see it. I know it was working fine this morning. I’m lost myself.

1 Like
6

It only generates that error if you don’t include the brackets.

If you change it to the following it should work:

runIn(60, deferredRefresh, [overwrite: true])

1 Like
7

Yes @vlad has pointed that out but he’s also looking into other stuff including why the stack trace is reversed.
This issue apparently never came to light because the live logging never showed the error until earlier today.

8

@vlad thanks for looking into this and sharing this the next point as well. For those curious about why the stack trace was reversed in order:

I guess when logging works it can solve mysteries or do the reverse, show bugs where none exist because nothing showed up for months :))

@slagle thanks for pushing this up.

Case closed!

1 Like