0

Consider a Step Function with a .net Lambda in it.

If the lambda throws an exception which contains a new line in the message, the Step Function does not recognise the type properly and instead reports:

Error

Lambda.Unknown

Cause

The cause could not be determined because Lambda did not return an error type.

The simplest repro is to create a .net lambda, and immediately throw an ArgumentNullException.

For our custom exceptions, I've been able to enforce no newlines. But for built in exceptions, this is a pain. Also, creating a custom exception and passing in the troublesome Exception as its inner exception still doesn't work.

I've had to resort to creating an exception that exposes the text of the original exception (removing newlines) so at least I can get the message out. However, because the Type of this exception is always the same, I lose the lovely branching available in the Step Functions depending on the type.

Note: I also think having double quotes in the message also messes things up.

Any ideas? I believe this is a bug in AWS and ideally I should be able to throw any exception and the Step Function would report it correctly.

Lee Oades
  • 1,638
  • 17
  • 24

1 Answers1

0

If the NL characters are the ones giving you the trouble you could use a wrapper around your lamdbdas to throw the same exception but without any NL, something like (assuming your lambdas return int):

public Func<int> BuildLambda(Func<int> orig) {
     return () => {
           try {
              return orig();
           } catch (Exception e) {
                 if (e.Message == null) throw e;
                 throw (Exception)Activator.CreateInstance(e.GetType(), e.Messsage.Replace("\n", "");
           }
     }
}
dcg
  • 4,187
  • 1
  • 18
  • 32
  • This was exactly what I tried to start with! The problem is that *a lot* of exceptions contain other information and properties and have different constructors accordingly. For example, the constructor for the ArgumentNullException which takes a single string isn't for the message - it is for the name of the property. I forget now but there was another exception that I caught (some network exception I think) and there was no matching constructor that took just a string and so my activator threw an activation exception. – Lee Oades Oct 25 '17 at 20:43
  • I didn't inferred from your question that you tried that, you only pointed out the issue with the `NL`s. In that case my answer solves nothing although I believe a better refined wrapper should do it. – dcg Oct 25 '17 at 20:52
  • I was trying to enthusiastically and supportively say "hey, that's a great idea and I tried that". I'd actually forgotten that that was my first angle of attack until I read your response (I've been trying to fix this for a while) so I apologise for not mentioning it. It's difficult to wrap without losing the ability to react to it in the Step Function. Best idea so far is to catch very specific exceptions where I know I want to retry and throw a TemporaryException (terrible name but you know what I mean) otherwise throw a more PermenantException and give up. – Lee Oades Oct 26 '17 at 00:58
  • @LeeOades Did you ever find a good solution for this? I'm new to Step Functions, and I'm getting the exact same error, and don't know how to best handle it. – LandonC Mar 30 '18 at 17:18
  • @LandonC - not really. I had to rework our internal exceptions so as not to contain newlines. Then I think I catch all exceptions at the highest level and check for newlines and if it contains any, throw a new StepFunctionSafe exception and copy the message to it, stripping out the newlines. At least I get the message then even though I can't react to it. That said, it all goes into the logs anyway. Let me know if you find a decent workaround! – Lee Oades Mar 31 '18 at 19:31