Closed jnordtorp-foreflight closed 11 months ago
Hi @jnordtorp-foreflight, thanks for flagging this. This is something we'd like to support, but it's unfortunately rather complex, so I can't give anytimelines. cc @purple4reina for visibility
@andrewlock It is something that datadog needs to support. More critically though, we need guidance on how to manually instrument lambdas while still using top level functions.
This pending change will affect anyone writing their dotnet core minimal API's with AWS' own hosting library
We are on the cusp of deciding whether to:
Understandable that you can't give any timelines, but how about a notion of how this is being prioritised? Is that possible? We would really appreciate at least a time range with which we could work with.
Thank you!
We have a dozen dotnet minimal apis and are also looking for this to be implemented. To echo what others are stating, AWS library is also using top-level statements and assembly references for handlers moving forward.
I've just encountered this issue. Has anyone found a workaround, or an alternative way of structuring an ASP.NET Core project that is compatible?
Don't want to +1 this thread too much, but I'm also running into this issue. Has there been any progress on this since it's been assigned?
Poll +1 on 🚀 If you use ASP.NET Core Minimal APIs. i.e. like this template +1 on 👀 If you use top-level statements but NOT Asp.net core. i.e. like this template.
Poll +1 on 🚀 If you use ASP.NET Core Minimal APIs. i.e. like this template +1 on 👀 If you use top-level statements but NOT Asp.net core. i.e. like this template.
We actually use top level statements in both minimal APIs and console type apps.
This feature should support Top-level statements regarding the type of project. When creating serverless API's a single use function is just a console application. So there is a function for at the minimal for each method type (Get, PUT, Delete ect) Then its not uncommon to have separate functions for Get USER vs Get USERS
Re-opened the issue since the layer is not released yet.
This is awesome and thanks for getting the Top level statements enabled for tracing.
Any timeline on when the new lambda layer version will be released?
The fix is now RELEASED!
It's available in dd-trace-dotnet version 2.41.0.
And Datadog AWS Lambda layers version 12
, i.e.
arn:aws:lambda:<region>:464622532012:layer:dd-trace-dotnet:12
arn:aws:lambda:<region>:464622532012:layer:dd-trace-dotnet-ARM:12
It's also reflected in serverless-plugin-datadog version 5.51.0.
We will also create a repo(WIP) in order to provide the layer release notes, which will include the underlying dd-trace-dotnet version info.
Are you requesting automatic instrumentation for a framework or library? Please describe. In the net6 runtime for aws lambda, they added support for top level statements. See
Is your feature request related to a problem? Please describe. Using top level statements, we change the function handler to only contain the assembly, but when initializing the tracer for serverless operation, the constructor expects the function handler to be formated as A::B::C, where as now we only provide A.
Describe the solution you'd like We would like support for using lambda top level statements