Adding exception message to return to CFN

[JohnPreston]

Adding message to the progress event for Exception and BaseException (strongly casted to str) to provide more insights on what the error was on __call__

Tested in private resource in CFN (by bunding code manually vs using cfn submit). Local sam tests and aws cloudformation test-type both pass with the change.

[JohnPreston]

Rebased from this master branch after hooks changes.

[jaymccon]

I believe that the current behavior is intentional as exception message may inadvertently leak data or implementation details (for closed source resources).

I suggest doing catch-all error handling in your handler code that returns a failed ProgressEvent with the exception text. This should ideally be done when iterating and removed when ready to distribute/publish your resource type.

[JohnPreston]

Right. I see your point. However, without the message attribute one would not know what is happenning.

I might be a weird edge case too but I am getting no log at all with 3 resources (in the log group) although they all past type testing. When used in CFN it totally fails and that is then the only way to get any indication of what might be wrong.

Maybe worth rewriting this with a feature switch so that one does not have to rework the whole cfn submit process manually

Edit: sorry misclicked on the close button :/

[ammokhov]

Right. I see your point. However, without the message attribute one would not know what is happenning.

I might be a weird edge case too but I am getting no log at all with 3 resources (in the log group) although they all past type testing. When used in CFN it totally fails and that is then the only way to get any indication of what might be wrong.

Maybe worth rewriting this with a feature switch so that one does not have to rework the whole cfn submit process manually

Edit: sorry misclicked on the close button :/

CW client is initialized on the runtime before handler method is invoked. If you dont get any logs it might indicate that error happened before request even reached your code. Such issues require debugging, so I would recommend creating a support ticket so CFN can securely investigate your private stacks and either provide a fix or a workaround.

Let's keep this issue opened for visibility and progress update.

[JohnPreston]

@ammokhov thanks. If that helps
Case 9598785821
At your convenience if you need any info/details

[JohnPreston]

PS: This PR / change I had to do to get any sort of feedback from the execution. So in CFN I do get the reason back with that change, but no matter where you set print/logging, nothing ever shows in CW Logs.

[JohnPreston]

Is there any progress that's been done on this ?
@jaymccon @ammokhov
Has the AWS Support team reached out at all on this from the Case ID I mentioned before ?

[darrylabbate]

Has the AWS Support team reached out at all on this from the Case ID I mentioned before ?

Yes, we've been contacted by Support regarding this issue (cc: #181, #182). We'll try to get some eyes on this as soon as we can.

Side note: it looks like the build CI started breaking, so we'll have to fix that as well. (EDIT: #183)

[darrylabbate]

I just want to echo @jaymccon's sentiment. These changes would significantly increase the risk of leaking implementation details for customers' resources, which is not something we want to impose on everyone who uses this library.

Even behind a feature flag/toggle (as you suggested), I feel this would be bad form overall.

[JohnPreston]

totally fine, since then figured the #182 was the reason for the lack of return at all.

[darrylabbate]

I'll go ahead and close this PR then, in favor of #181/#182. Thanks John.