SDK Binding Bug Bash Discussion

[liliankasem]

A general discussion page to capture any comments or feedback during the SDK Binding Bug Bash.

[liliankasem]

When binding to BlobContainerClient as an input binding, you still need to provide a blob name in the input binding i.e. BlobInput("input-container/sample1.txt"

[Function(nameof(BlobContainerClientInputFunction))]
public async Task<HttpResponseData> BlobContainerClientInputFunction(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req,
    [BlobInput("input-container/sample1.txt")] BlobContainerClient client)

But since we are binding to a container, it doesn't make sense to have to provide a blob name in the binding; instead I would expect that you could bind to just the container like this:

[Function(nameof(BlobContainerClientInputFunction))]
public async Task<HttpResponseData> BlobContainerClientInputFunction(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req,
    [BlobInput("input-container")] BlobContainerClient client)

This does not work today and you get the following error message:

Invalid blob path specified : 'input-container'. Blob identifiers must be in the format 'container/blob'

Note: this is different to a blob trigger which lets you bind to just the container, and it is not the same as IsBatched which also lets you bind to only a container but expects a collection binding i.e. BlobContainerClient[] which does not make sense for this scenario

[liliankasem]

Not related to this feature, but when deploying a function app from VS Code to the portal, my settings in local.settings.json were updated to the function app in the portal when they should not have been.

[cloudmelon]

I tested blob input binding & trigger, all worked well, only failed for the large file upload ( e.g. 4.8 GB MP4 )

For the large file, my resources are here,

1. local development running for 20 mins, failed
2. FunctionApp - EP1, failed

Repro steps :

1. input bindings code :

 [Function(nameof(BlobClientInputFunction))]
        public async Task<HttpResponseData> BlobClientInputFunction(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req,
            [BlobInput("input-container/Dreamlight Ariel.mp4")] BlobClient client)
        {
            var downloadResult = await client.DownloadContentAsync();
            var content = downloadResult.Value.Content.ToString();

            _logger.LogInformation("Blob content: {content}", content);

            return req.CreateResponse(HttpStatusCode.OK);
        }
    }

the MP4 is a 4.x large file

3. trigger :
   publish code to function app (EP1), add mp4 file to blob storage, it shows 500 server error
   code as the following :

  [Function(nameof(BlobClientInputFunction))]
        public async Task<HttpResponseData> BlobClientInputFunction(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req,
            [BlobInput("input-container/Dreamlight Ariel.mp4")] BlobClient client)
        {
            var downloadResult = await client.DownloadContentAsync();
            var content = downloadResult.Value.Content.ToString();

            _logger.LogInformation("Blob content: {content}", content);

            return req.CreateResponse(HttpStatusCode.OK);
        }

[liliankasem]

Hey @cloudmelon, thanks for writing up the details.

A string scenario like this for a large payload is not expected to work.

var downloadResult = await client.DownloadContentAsync();
var content = downloadResult.Value.Content.ToString();

Here we are reading the content of the blob as a string to memory; reading the entire content/stream to memory will be limited by the amount of memory available to you in the environment, so an exception there is expected, even in the portal. This is the same limitation as with in-proc and so the guidance we provide is that string, byte[] and similar types should only be used with small payloads.

For large payloads, we expect folks to read and flush the content to another stream (e.g, a network stream, file stream, HTTP response, etc.). Here's a blob copy sample as an example.

One example is binding to a stream and writing it to a blob:

[Function(nameof(BlobCopyStreamFunction))]
public async Task<HttpResponseData> BlobCopyStreamFunction(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req, string filename,
    [BlobInput("input-container/{filename}")] Stream stream)
{
    _logger.LogInformation("Blob copy from stream");
    try
    {
        var connectionString = Environment.GetEnvironmentVariable("AzureWebJobsStorage");
        var container = new BlobContainerClient(connectionString, "output-container");

        await container.UploadBlobAsync(Guid.NewGuid() + "-" + filename, stream);

        var response = req.CreateResponse(HttpStatusCode.OK);
        await response.WriteStringAsync("Saved stream to file!");
        return response;
    }
    catch (Exception ex)
    {
        _logger.LogError($"Exception in BlobCopyStreamFunction: {ex.Message}");
        var response = req.CreateResponse(HttpStatusCode.InternalServerError);
        await response.WriteStringAsync("Failed to upload file");
        return response;
    }
}

cc: @fabiocav if I missed anything or you have anything to add!

[cloudmelon]

We should eval this and get a good understanding of service limits here. Using SDK type binging so functions can stream data incrementally and process larger blobs than it could before ( 100MB -> as documented here but it wasn't accurate). Adding service limits : https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale#service-limits

This is related item for doc update of this feature : #1344

[fabiocav]

Closing discussion for completed activity