Bug: Tracing does not work with Top Level Lambda functions

[nCubed]

Expected Behaviour

When using .net/C# Top Level Lambda functions, tracing, trace details should be available in AWS X-Ray traces console.

does not appear to be working.

Current Behaviour

When using .net/C# Top Level Lambda functions, tracing, trace details are not available in AWS X-Ray traces console.

Code snippet

using System.Drawing;
using System.Reflection;
using System.Text.Json;
using System.Text.Json.Serialization;
using Amazon.Lambda.Core;
using Amazon.Lambda.RuntimeSupport;
using Amazon.Lambda.Serialization.SystemTextJson;
using AWS.Lambda.Powertools.Logging;
using AWS.Lambda.Powertools.Tracing;

await LambdaBootstrapBuilder.Create((Func<string, ILambdaContext, Task<string>>)Handler, new DefaultLambdaJsonSerializer())
        .Build()
        .RunAsync();

[Tracing]
[Logging]
async Task<string> Handler(string input, ILambdaContext context)
{
    LogAssembly();

    string json = await CreateAnonObjectAsJson(input);

    Logger.LogInformation(json);

    return await Task.FromResult(json);
}

[Tracing]
void LogAssembly()
{
    Assembly a = Assembly.GetAssembly(typeof(Logger))!;
    Logger.LogInformation(a.FullName);
    Logger.LogInformation(Pet.Lizard);
    Logger.LogInformation(Thing.Three);
    Logger.LogInformation(Color.MediumVioletRed);
}

[Tracing]
async Task<string> CreateAnonObjectAsJson(string input)
{
    var val = new
    {
        input,
        utcDate = DateTime.UtcNow.ToString("s"),
        date = DateTime.Now.ToString("s"),
        pet = Pet.Lizard,
        thing = Thing.Three
    };

    string json = JsonSerializer.Serialize(val, new JsonSerializerOptions { WriteIndented = true });

    await Task.Delay(690);

    return json;
}

[JsonConverter(typeof(JsonStringEnumConverter))]
public enum Pet
{
    Cat = 1,
    Dog = 3,
    Lizard = 5
}

public enum Thing
{
    One = 1,
    Three = 3,
    Five = 5
}

Possible Solution

I suspect this may be related to a similar issue we found with Top Level statement functions and the logger. See #656

Steps to Reproduce

Run the sample, view the x-ray console, no tracing other than the standard traces exist.

Powertools for AWS Lambda (.NET) version

1.6.0

AWS Lambda function runtime

dotnet8

Debugging logs

v1.6.2 PowerTools.Logging
v1.6.0 PowerTools.Tracing

[nCubed]

@hjgraca - has your team been able to repro this issue? Our team is trying to use the Tracing tools in the PowerTools and this is currently blocking us. The convenience is great and I really do not want to start injecting DataDog dependencies and traces into the code.

[hjgraca]

@nCubed - yes, we were able to reproduce the issue. Currently working on a fix, hope to get it out early next week.

[hjgraca]

@nCubed - I am currently going over the code and everything seems to be fine.
The issue seems to be the name of the segment that gets generated when using top level statements.
As a work around if you specify the SegmentName it works as expected.

using System.Text.Json;
using Amazon.Lambda.Core;
using Amazon.Lambda.RuntimeSupport;
using Amazon.Lambda.Serialization.SystemTextJson;
using AWS.Lambda.Powertools.Tracing;


await LambdaBootstrapBuilder.Create((Func<string, ILambdaContext, Task<string>>)Handler, new DefaultLambdaJsonSerializer())
        .Build()
        .RunAsync();

[Tracing(SegmentName = "My Handler")]
async Task<string> Handler(string input, ILambdaContext context)
{
    
    string json = await CreateAnonObjectAsJson(input);

    return await Task.FromResult(json);
}

[Tracing(SegmentName = "My Mehod")]
async Task<string> CreateAnonObjectAsJson(string input)
{
    var val = new
    {
        input,
        utcDate = DateTime.UtcNow.ToString("s"),
        date = DateTime.Now.ToString("s"),
    };

    string json = JsonSerializer.Serialize(val, new JsonSerializerOptions { WriteIndented = true });

    return json;
}

I will continue to investigate but I believe this will unblock you.

[hjgraca]

@nCubed - As mentioned above the issue is with the string that gets generated from the top level statement handler.
In this example the generated string is ## <<Main>$>g__Handler|0_0 which breaks the accepted characters for segment name defined in the X-Ray documentation.

I am going to close this issue and open another issue that better reflects the issue we have, we are going to do two things, first add a summary to the SegmentName property that shows what are the accepted characters and also sanitize the string generated by the handler/methods were no SegmentName is defined.

Thank you so much for reporting this, really appreciate your time.

[nCubed]

@hjgraca Thanks for the update. Been a busy last couple of days. I'll add named segments and give it a go next week. If possible, could you tag me in the work item addressing this issue so I can follow?

[nCubed]

@hjgraca - was able to verify the workaround with the segment names. Looks good. Looking forward to the new release. Thanks!