I totally agree that calling unschedule() takes a long time. In the past few minutes as I’ve been looking at this thread, the average time to unschedule was right around 3 seconds, which is close to what you were seeing. I did see some very fast ones too, around 4 ms, but that didn’t seem to be the normal. Even with 3 seconds, that is a good chunk of the 20 second total allowed, and if it slows down I’m not surprised you were seeing the TimeoutExceptions.
Unschedule actually has to do a number of things like finding all the jobs for this installation of the SmartApp and cleaning up data in a number of (very large) tables. I don’t have the data to prove it, but I assume the problem is getting worse over time.
For now, I know that doesn’t help much, and I’m sorry. Soon (hopefully) we’ll be rolling out a new scheduling mechanism behind the scenes that should be better able to handle this with much larger volumes of customers.
I’ve asked another SmartThings developer to chime in on this part. I think the SmartApp just gets shut down at the point of the timeout. It will run again if there are more schedules or subscriptions. In this case I think the unschedule() should finish, even if the exception is thrown, but I’ll let me colleague correct me if I’m wrong.