Quic protocol support for invoking AWS Lambda

[bykka]

Hi,

I have a problem invoking one lambda from another one. Both lambdas use .Net6 environment.
In the majority of cases, everything works fine but sometimes it fails with the next exception:

System.IO.FileLoadException: Could not load file or assembly 'System.Net.Quic, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot open the file.
 (0x80070004)
File name: 'System.Net.Quic, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at System.Reflection.CustomAttribute._CreateCaObject(RuntimeModule pModule, RuntimeType type, IRuntimeMethodInfo pCtor, Byte** ppBlob, Byte* pEndBlob, Int32* pcNamedArgs)
   at System.Reflection.CustomAttribute.AddCustomAttributes(ListBuilder`1& attributes, RuntimeModule decoratedModule, Int32 decoratedMetadataToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, ListBuilder`1 derivedAttributes)

Code example:

var _lambdaClient = new AmazonLambdaClient();
 _lambdaClient.InvokeAsync(new()
  {
      FunctionName = "my-next-function",
      InvocationType = InvocationType.Event,
      Payload = JsonSerializer.Serialize(request)
  });

For me, it looks like the lambda client has got a request to upgrade the protocol to version HTTP3. But according to the MS Documentation looks like this protocol became supported as a preview feature only in .Net7.

Does someone know how to fix it and why such an issue happens just time to time?

[normj]

The SDK and Lambda only support HTTP 1.1. There is nothing in the SDK that would attempt HTTP3, there are no AWS services that support HTTP3. I suspect the problem is coming from some where else in your application or something special on your environment that is trying to elevate the HTTP version, not sure what that would be though.

[bykka]

Thank you for your reply,

I execute my code in the lambda environment and do not control what happens there.
According to the log, it uses .net6.v44
INIT_START Runtime Version: dotnet:6.v44

And as I mentioned it is not a persistent issue - it happens only occasionally.

I would like to ask you what do you think, Is it possible that the standard AWS Lambda environment is not properly initiated?
Or is it a 100% issue on my side?

[normj]

I missed your code was running in Lambda. I was thinking maybe some IIS setting or policy was pushing for a higher version of HTTP but given you are running in Lambda that doesn't make sense. I can't see how anything in Lambda would try and upgrade the HTTP version. Sorry but I believe this is something going on in your side. The stacktrace's call stack does not call out as being part of the SDK call. Are you sure this exception is happening, occasionally, from the SDK's InvokeAsync call?

[bykka]

It looks like I have another issue that causes dll loading - too many open files. But I do not work with files in the lambda - simply process dynamodb stream events and invoke another lambda in the end.

[bykka]

I guess this article describes a similar case that I have got https://ttlnews.blogspot.com/2023/07/too-many-open-files-in-aws-lambda.html

In two worlds: at night, when my lambda gets bursts of messages to process it opens to many HTTP connections (each new connection uses a file descriptor) for sending a message to another lambda.