BlobTrigger payload expression binding not working as expected

[liliankasem]

When using a queue trigger binding with a blob input binding, the following example works as expected. In this example, we are able to parse the payload of myBook and use the id to evaluate input-container/{id}.txt to input-container/1.txt

QueueTrigger/index.js

import { AzureFunction, Context } from "@azure/functions"

const queueTrigger:
    AzureFunction = async function (context: Context, myBook: Book): Promise<void>
    {
        context.log("Queue trigger function processed blob");
        context.log("Book name:", myBook.name);
        context.log("Book content:", context.bindings.myBlob);
    };

type Book = {
    id: string,
    name: string,
}

export default queueTrigger;

function.json

{
  "bindings": [
    {
      "name": "myBook",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "book-trigger",
      "connection": "AzureWebJobsStorage"
    },
    {
      "name": "myBlob",
      "type": "blob",
      "direction": "in",
      "path": "input-container/{id}.txt",
      "connection": "AzureWebJobsStorage"
    }
  ],
  "scriptFile": "../dist/QueueTrigger/index.js"
}

Trigger payload:

{ "id": "1", "name": "mybook" }

Output:

[2022-10-25T22:58:17.636Z] Executing 'Functions.QueueTrigger' (Reason='New queue message detected on 'book-trigger'.', Id=e4545b2a-0fe5-4f08-aed5-705f24dfc2a3)
[2022-10-25T22:58:17.637Z] Trigger Details: MessageId: fd82d6a8-40dd-4275-a700-51c394e5bc1c, DequeueCount: 1, InsertedOn: 2022-10-25T22:58:15.000+00:00
[2022-10-25T22:58:17.857Z] Queue trigger function processed blob
[2022-10-25T22:58:17.858Z] Book name: mybook
[2022-10-25T22:58:17.858Z] Book content: hello world
[2022-10-25T22:58:17.884Z] Executed 'Functions.QueueTrigger' (Succeeded, Id=e4545b2a-0fe5-4f08-aed5-705f24dfc2a3, Duration=270ms)

This behaviour is also expected to work for the BlobTrigger

BlobTrigger/index.js

import { AzureFunction, Context } from "@azure/functions"

const blobTrigger:
    AzureFunction = async function (context: Context, myBook: Book): Promise<void>
    {
        context.log("Blob trigger function processed blob")
        context.log("Book name:", myBook.name);
        context.log("Book content:", context.bindings.myBlob);
    };

type Book = {
    id: string,
    name: string,
}

export default blobTrigger;

function.json

{
  "bindings": [
    {
      "name": "myBook",
      "type": "blobTrigger",
      "direction": "in",
      "path": "book-trigger",
      "connection": "AzureWebJobsStorage",
      "dataType": "string"
    },
    {
      "name": "myBlob",
      "type": "blob",
      "direction": "in",
      "path": "input-container/{id}.txt",
      "connection": "AzureWebJobsStorage",
      "dataType": "string"
    }
  ],
  "scriptFile": "../dist/BlobTrigger/index.js"
}

Trigger payload (book.json)

{ "id": "1", "name": "mybook" }

Output

[2022-10-25T22:58:52.738Z] Executing 'Functions.BlobTrigger' (Reason='New blob detected(LogsAndContainerScan): book-trigger/book.json', Id=a8c7a83f-f490-43a1-a6ca-955f554c19b5)
[2022-10-25T22:58:52.738Z] Trigger Details: MessageId: 3a6ad397-27ca-47d3-b012-5973cd36a039, DequeueCount: 1, InsertedOn: 2022-10-25T22:58:52.000+00:00, BlobCreated: 2022-10-25T21:39:49.000+00:00, BlobLastModified: 2022-10-25T22:58:42.000+00:00
[2022-10-25T22:58:52.785Z] Executed 'Functions.BlobTrigger' (Failed, Id=a8c7a83f-f490-43a1-a6ca-955f554c19b5, Duration=116ms)
[2022-10-25T22:58:52.785Z] System.Private.CoreLib: Exception while executing function: Functions.BlobTrigger. Microsoft.Azure.WebJobs.Host: No value for named parameter 'id'.

We should have seen is a similar result to what happened with the queue trigger:

Book name: mybook
Book content: hello world

Interestingly, when we remove the use of the blob input binding and just use a blob trigger by itself, still binding to a Book, instead of getting the payload as a Book, we get binary data (even if the data type is set to string):

{
  "bindings": [
    {
      "name": "myBook",
      "type": "blobTrigger",
      "direction": "in",
      "path": "book-trigger",
      "connection": "AzureWebJobsStorage",
      "dataType": "string"
    }
  ],
  "scriptFile": "../dist/BlobTrigger/index.js"
}

[2022-10-25T23:01:19.747Z] Executing 'Functions.BlobTrigger' (Reason='New blob detected(LogsAndContainerScan): book-trigger/book.json', Id=75277b64-3197-477c-afeb-044a30253ce6)
[2022-10-25T23:01:19.748Z] Trigger Details: MessageId: 9bd797ac-a7d8-477e-8516-791ae788c6c2, DequeueCount: 1, InsertedOn: 2022-10-25T23:01:19.000+00:00, BlobCreated: 2022-10-25T21:39:49.000+00:00, BlobLastModified: 2022-10-25T23:01:11.000+00:00
[2022-10-25T23:01:19.821Z] Blob trigger function processed blob
[2022-10-25T23:01:19.821Z] MyBook: <Buffer 7b 20 22 69 64 22 3a 20 22 31 22 2c 20 22 6e 61 6d 65 22 3a 20 22 6d 79 62 6f 6f 6b 22 20 7d>
[2022-10-25T23:01:19.821Z] Book name: undefined
[2022-10-25T23:01:19.849Z] Executed 'Functions.BlobTrigger' (Succeeded, Id=75277b64-3197-477c-afeb-044a30253ce6, Duration=205ms)

We would expect to get a POCO as we have logic in the host here that pulls json values from the payload if it's a String. We can see this in action with the queue trigger example.

• The goal of this issue is to investigate why the payload binding expression is not working for the BlobTrigger

[ejizba]

I don't know why this is, but AFAIK we're just handling what the host gives us. Specifically, here is the invocation we get for a queue trigger with data set to "string" and for a blob trigger with data set to "bytes":

Are we sure that's not by design on the host's part? I would understand if a file was handled differently than a queue entry

[liliankasem]

If that's the case, this is probably a host or WebJobs sdk issue (I can transfer issue). We should not be giving you bytes in this use case 🙃

[ejizba]

I'm pretty sure it has been like this for a long time, though, so it would definitely be a breaking change

[liliankasem]

Yup it will be a breaking change, so something we might discuss for 5.0. This is tied to this underlying issue. There was a commit made to add batch types that broke the expected behaviour in 2019 ☠️

I'll keep this open to validate this use case if we fix it in the WebJobs SDK. Otherwise if we don't have plans to address it then I can close this out. But I think we can't get parity with in-proc for OOP workers without fixing this.