Log error when failing to schedule re-invocation

[arnulfojr]

Description of changes:

At the moment, when the handler fails to schedule a re-invocation the error message is not displayed in any manner and is hard to guess what was the error of the stack when the handlers succeed on "handling" the resource operation.

This at least will make it easier for the operator to know the details of the error.

Not a required change, just making life easier in the meantime

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[miparnisari]

Suggested change

	} catch (final Throwable e) {
	log(String.format("Failed to schedule re-invoke, %s", e.getMessage()));
	handlerResponse.setMessage("Failed to schedule re-invoke.");
	} catch (final Throwable e) {
	handlerResponse.setMessage("Failed to schedule re-invoke: " + e.getMessage());

[arnulfojr]

Hey, thanks for the review!

I see that this was previously removed. It might not also be a good idea to add it back again. Makes sense to "not" leak info back to the customer as this is internal to the service. I just thought of adding it to the log so the operator of the resource can at least know what's failing.

52114e3#diff-dfc0e730cbc8e8034297955f8255ceb7

Is there something in the throwable that can be a potential leak if we add it to the log?
I'm not very familiar with Java's serialization to string.

[rjlohan]

This change might be made redundant by #279 as we have changed the model for re-invocation to allow us to increase some limits (which may have been the very things causing the re-invoke to fail for you).