Service
Azure Functions / Blob Storage
API Action / Feature
Blob trigger (event-driven function invocation on blob create/update)
AWS Documentation
Why is this needed?
The hosted Functions runtime is HTTP-triggered only today (/api/{app}/{func}, warm-pool-on-invoke), which is documented and expected. This asks specifically for a Blob trigger as an event source: writing a blob invokes a deployed function, the way blobTrigger bindings work in real Azure.
Use case: we have functions that run on blob upload (ingest/transform pipelines). Locally there is no way to test them end to end against floci-az — a function deployed with a blobTrigger binding is accepted, but writing a blob never invokes it, and nothing is logged. The result is a silent gap: the write succeeds, the function never runs, and there is no signal pointing at the missing capability (same shape as #209's StorageQueue case).
This is distinct from #136 (Durable/Timer storage-driven bindings) and from PR #183 (blob lease support for a BYO Functions host pointed at floci-az as AzureWebJobsStorage). Neither makes the emulator's own runtime fire a function when a blob lands.
Ideal: on blob create/update in a watched container, invoke the matching blobTrigger function with the standard payload. If that is out of scope, at minimum reject blobTrigger at deploy time with an error listing the supported trigger types, so the gap is obvious in seconds instead of surfacing as a function that silently never runs.
Are you willing to contribute a PR?
Service
Azure Functions / Blob Storage
API Action / Feature
Blob trigger (event-driven function invocation on blob create/update)
AWS Documentation
Why is this needed?
The hosted Functions runtime is HTTP-triggered only today (
/api/{app}/{func}, warm-pool-on-invoke), which is documented and expected. This asks specifically for a Blob trigger as an event source: writing a blob invokes a deployed function, the wayblobTriggerbindings work in real Azure.Use case: we have functions that run on blob upload (ingest/transform pipelines). Locally there is no way to test them end to end against floci-az — a function deployed with a
blobTriggerbinding is accepted, but writing a blob never invokes it, and nothing is logged. The result is a silent gap: the write succeeds, the function never runs, and there is no signal pointing at the missing capability (same shape as #209's StorageQueue case).This is distinct from #136 (Durable/Timer storage-driven bindings) and from PR #183 (blob lease support for a BYO Functions host pointed at floci-az as
AzureWebJobsStorage). Neither makes the emulator's own runtime fire a function when a blob lands.Ideal: on blob create/update in a watched container, invoke the matching
blobTriggerfunction with the standard payload. If that is out of scope, at minimum rejectblobTriggerat deploy time with an error listing the supported trigger types, so the gap is obvious in seconds instead of surfacing as a function that silently never runs.Are you willing to contribute a PR?