Azure-functions-host: Run Fails for (in) Blob Binding If Blob Doesn't Exist

Created on 6 Jul 2017  路  5Comments  路  Source: Azure/azure-functions-host

If an blob binding has the in or inout direction and that blob does not exist, the function will not run.

This makes it impossible to check whether a blob exists or use input direction for any blob that may not exist.

Investigative information

Please provide the following:

  • Timestamp: 2017-07-06T20:04:50.157
  • Function App name: told-stack-demo
  • Function name(s) (as appropriate): lookup-lsc-01-http
  • Invocation ID: 9cc99405-8ee7-4b98-b7c6-bbdeb8afc82b
  • Region: East US 2

Using in direction:

2017-07-06T20:04:50.157 Function started (Id=9cc99405-8ee7-4b98-b7c6-bbdeb8afc82b)
2017-07-06T20:04:50.173 Function completed (Failure, Id=9cc99405-8ee7-4b98-b7c6-bbdeb8afc82b, Duration=10ms)
2017-07-06T20:04:50.338 Exception while executing function: Functions.lookup-lsc-01-http. mscorlib: Value cannot be null.
Parameter name: stream.

Using inout direction:

2017-07-06T19:51:11.227 Function started (Id=c06d64d0-0c75-4ea8-96f5-3151852d5dff)
2017-07-06T19:51:11.227 Function completed (Failure, Id=c06d64d0-0c75-4ea8-96f5-3151852d5dff, Duration=1ms)
2017-07-06T19:51:11.274 Exception while executing function: Functions.lookup-lsc-01-http. Microsoft.Azure.WebJobs.Host: Cannot bind blob to Stream using FileAccess ReadWrite.

Repro steps

Provide the steps required to reproduce the problem:

  1. Request the function url: https://told-stack-demo.azurewebsites.net/api/lookup-lsc/test/test/abc

Expected behavior

Provide a description of the expected behavior.

  • It runs
  • It should print 'START':
  • context.log('START'); is the first line at the top of the function body

Actual behavior

Provide a description of the actual behavior observed.

  • It throws an exception
  • It never enters the function body but appears to throw an exception during the binding process

Known workarounds

Provide a description of any known workarounds.

Not using binding functionality for any input blob that may not exist, but instead using the Azure Storage SDK to access the blob manually.

Related information

Provide any related information

Example function.json:

{
 "bindings": [
  {
   "name": "req",
   "type": "httpTrigger",
   "direction": "in",
   "authLevel": "anonymous",
   "route": "api/http-input-blob/{container}/{*blob}"
  },
  {
   "name": "res",
   "type": "http",
   "direction": "out"
  },
  {
   "name": "inInputBlob",
   "type": "blob",
   "direction": "in",
   "path": "{container}/{blob}",
   "connection": "AZURE_STORAGE_CONNECTION_STRING"
  }
 ],
 "disabled": false
}

Example Source at: https://github.com/toldsoftware/told-stack/blob/master/told-stack-npm/src/data-patterns/http-input-blob/src-server/function-01-http.ts

bug needs-investigation

Most helpful comment

Why not set it to null as occurs for Table Storage when a matching entity of a given key is not found?

There are many use cases that cannot be done without this:

  • Return a not found http status code for http trigger and input blob binding
  • Check if a blob exists
  • Read from an input blob with a fixed default backup value
  • Create or Update a blob

So by design the input blob is only useful for fixed blob routes (and using http routing to point to a blob with a dynamic blob name is essentially useless because there is no way to handle the not found case in user land).

All 5 comments

This behavior is by design. If the resource may not exist at execution time then avoid using an input binding.

Why not set it to null as occurs for Table Storage when a matching entity of a given key is not found?

There are many use cases that cannot be done without this:

  • Return a not found http status code for http trigger and input blob binding
  • Check if a blob exists
  • Read from an input blob with a fixed default backup value
  • Create or Update a blob

So by design the input blob is only useful for fixed blob routes (and using http routing to point to a blob with a dynamic blob name is essentially useless because there is no way to handle the not found case in user land).

Agreed - this is breaking a use case I had for an azure function which first checked whether a blob exists.

@paulbatum

Where can we go to request this design be changed?

It is a serious limitation that prevents most use cases for blob binding.

Understood. I opened https://github.com/Azure/azure-webjobs-sdk/issues/1326 to track. Please comment on this issue further with more specifics on how you would like to see this work.

Was this page helpful?
0 / 5 - 0 ratings