Using internal extensions to perform actions after the function finishes

[martinjt]

I had an idea to replicate what an external extension does, but using an internal extension. The goal being to remove the need for a layer.

I've managed to get the PoC working, however, I think I'm missing something in how extensions works as it's extending the response time of the function.

The idea I had was to register the extension in a BackgroundService, then sit and wait there for the INVOKE action. Then when I get that, wait for the notification that the function is finished (for this I'm using an ActivityListener), do an action.

What I've found is that if my action takes a few seconds, even though the function responds in 10ms, the net effect to someone hitting the API is that it takes a few seconds.

I'm assuming that I'm missing something with the way that internal extensions work, in that they don't run after the response like an external extension?

[normj]

Hi @martinjt. My understanding as well is that the extensions should not extend the response time that the caller of the Lambda function sees as like as the function handler returns. Is your PoC somewhere online for me to check out?

[martinjt]

https://github.com/practical-otel/otel-dotnet-lambda-extension

The code's a mess, and it took me a while to workout a few things... so if there's something obvious I may just find it tomorrow with a clear head, but do let me know if you have time to look.

It's also possible that this is specific to using SAM local for development?

[normj]

Closing the loop after debugging with @martinjt in side channels. Martin's issue appears to be specific to SAM local emulation. When deployed to Lambda we see response being returned to the browser right away but the record function invocation includes the time spent in the internal extension. This match both of our expectations.