Lambda Powertools @Tracing failures due to leveraging XRAY SDK internal ObjectMapper

[allenada]

Currently the @Tracing annotation of Powertools writes to XRAY subsegment using XRAY SDK. Tracing the code of XRAY back to the source, it leverages this internal instance of Jackson's ObjectMapper in the EntityImpl class

This has caused me two problems in developing with Lambda Powertools

1. In an upgrade from Jackson 2.11 to 2.12, I started seeing failures of methods annotated with @Tracing due to behavior in Jackson 2.12 to fail serialization of java8 time types when the JSR310 module wasn't registered to ObjectMapper (see here). This is fixed if using the current version of XRAY SDK and findAndRegisterModules can detect the JSR310 dependency and register it. If JSR310 is not you dependency though, you get an error message that is difficult to debug since you have to trace the failure through the powertools aspect and back through XRAY SDK.

2. In @Tracing a method that returns an object with a circular reference, @Tracing causes failure for a similar reason as that instance of ObjectMapper in XRAY SDK doesn't know how to deal with the circular reference. The way to overcome this is to ensure classes are annotate correctly to resolve the circular reference. This strategy only works if the user can modify the source code of such classes though. If he cannot then he is left using ByteBuddy or something similar to impose annotations on the class. Also seems odd that a user would need to add Jackson annotations if his preferred serialization was not Jackson just to ensure that powertools tracing works correctly..I think the requirement for such annotations is an encapsulation break

Expected Behavior

At the least not failing in the event of the Tracing Aspect code getting exception from XRAY SDK serialization

Possible Solution

I think there are possibly two strategies to take to improve experience with powertools:

1. Powertools to gracefully handle failure of @Tracing, maybe just log warnings and do not log anything in the trace rather than allowing the Jackson exception to bubble out and cause failure
2. Possibly allow user to give custom serializer to powertools so that that serializer is independent of the default XRAY SDK one. This would allow a custom ObjectMapper, GSON, etc instance to handle serialization to string of the response/error from methods and then we'd be essentially free of the XRAY SDK ObjectMapper instance

Steps to Reproduce (for bugs)

1. Create some class with self-reference eg

public class ParentClass {
  public String name;
  public ChildClass c;
}

public class ChildClass {
  public String name;
  public ParentClass p;
}

2. Annotate a method with @Tracing to a Lambda handler and have it return the class with self-reference
3. Run Lambda handler in AWS and see it fail when the Tracing aspect is invoked

[msailes]

Hi @allenada,

Thanks for the bug report. I'll have a look at it in the new year.

Thanks,

[pankajagrawal16]

Simple solution would be to not depend on Xray SDK for serialization and take control of it in the powertools tracing module itself.

[github-actions]

This is now released under 1.10.2 version!

[heitorlessa]

Look at this bot nicely tidying up now @pankajagrawal16