Currently, since there is no local emulator of the EventGrid service, EventGrid-based blob trigger functions are not automatically triggered when a blob is uploaded to the relevant blob container. Instead, after the blob is uploaded or updated, the user has to manually click on "Execute Function" then manually choose the blob they just uploaded/updated.
In Flex Consumption, regular blob trigger functions will no longer be supported. As such, EventGrid-based blob trigger functions will be the only option. It is therefore important to make sure that the local development story for EventGrid-based blob trigger functions is as close to regular blob trigger functions as possible. Ideally, the user won't even have to know it is even EventGrid-based.
Since there is no local emulator of an EventGrid-service, making sure that the function is automatically triggered on blob upload/update is challenging, but here are some options:
Create a local EventGrid service emulator:
The closest analogy to the Azure experience and code path would be to create an EventGrid service emulator since none exists. This entails created a process that listens for events published from the storage account, and triggering the function when a blob create/update event is detected. However, there is an extra challenge to this path, which is that Azurite, the local storage emulator, does not currently publish those events or support the blob change feed: https://github.com/Azure/Azurite/issues/1349
To achieve parity in this option between local emulator experience and Azure storage account experience, it would require us to implement the blob change feed feature in Azurite (alone a huge task), or push the Azurite team to do it.
Emulate the behavior through polling
In the actual Azure implementation of this path, the EventGrid service listens to events published by the storage account, rather than polling the storage account for changes. However, locally, we can emulate this behavior by instead polling the storage account and sending a request when a relevant change is detected. This avoids us having to implement the blob change feed feature in Azurite, but it has the disadvantage of being a different code path than the real Azure experience.
Currently, since there is no local emulator of the EventGrid service, EventGrid-based blob trigger functions are not automatically triggered when a blob is uploaded to the relevant blob container. Instead, after the blob is uploaded or updated, the user has to manually click on "Execute Function" then manually choose the blob they just uploaded/updated.
In Flex Consumption, regular blob trigger functions will no longer be supported. As such, EventGrid-based blob trigger functions will be the only option. It is therefore important to make sure that the local development story for EventGrid-based blob trigger functions is as close to regular blob trigger functions as possible. Ideally, the user won't even have to know it is even EventGrid-based.
Since there is no local emulator of an EventGrid-service, making sure that the function is automatically triggered on blob upload/update is challenging, but here are some options:
Create a local EventGrid service emulator:
The closest analogy to the Azure experience and code path would be to create an EventGrid service emulator since none exists. This entails created a process that listens for events published from the storage account, and triggering the function when a blob create/update event is detected. However, there is an extra challenge to this path, which is that Azurite, the local storage emulator, does not currently publish those events or support the blob change feed: https://github.com/Azure/Azurite/issues/1349
To achieve parity in this option between local emulator experience and Azure storage account experience, it would require us to implement the blob change feed feature in Azurite (alone a huge task), or push the Azurite team to do it.
Emulate the behavior through polling
In the actual Azure implementation of this path, the EventGrid service listens to events published by the storage account, rather than polling the storage account for changes. However, locally, we can emulate this behavior by instead polling the storage account and sending a request when a relevant change is detected. This avoids us having to implement the blob change feed feature in Azurite, but it has the disadvantage of being a different code path than the real Azure experience.