如何配置订阅仅在Blob完全提交后触发Blob Created事件？

问题场景 #

我们部署了带eventHubTrigger的Azure Function，用于读取Apache NiFi创建的Blob。通过过滤EventGridSchema的Blob Created事件实现功能，整体运行正常，但偶尔会出现Azure Function在Blob完全提交前就获取到该Blob的情况。

使用的是带分层命名空间的BlockBlobStorage类型存储账户。从StorageBlobLogs可见，正常操作序列为：NiFi处理器依次执行CreatePathFile > AppendFile > FlushFile，随后Azure Function执行Getblob > DeleteBlob。出问题时，GetBlob操作会先于FlushFile甚至AppendFile执行。

目前观察到仅CreatePathFile操作会触发Blob Created事件，官方文档显示FlushWithClose操作也应触发该事件，但尝试对data.api设置事件过滤器后，直接导致函数完全停止运行，未解决问题。

解决思路及配置步骤 #

• 精准配置事件过滤规则
  之前过滤器失效导致函数停转，大概率是规则格式或取值错误。针对分层命名空间的BlockBlobStorage，需添加高级筛选器：选择字段data.api，操作符设为等于，值严格填FlushWithClose（注意大小写敏感，不能写错）。仅保留该操作触发的Blob Created事件，就能确保事件在Blob完全提交后才推送。

• 确认NiFi写入操作的正确性
  检查NiFi处理器的最终写入逻辑，确保执行的是FlushWithClose而非普通FlushFile。只有触发FlushWithClose操作，才会生成Blob提交完成对应的事件，普通FlushFile不会触发该事件。

• 添加Blob完整性校验兜底
  极端场景下可能存在事件延迟或异常，建议在Azure Function中补充校验逻辑：

  • 获取Blob后，检查Properties.ContentLength是否符合预期值；
  • 验证Blob的ETag是否处于稳定状态（提交完成的Blob ETag不会再变更）；
  • 若校验不通过，将Blob放入重试队列（如Azure Storage Queue），延迟一段时间后再处理。

• 检查存储账户事件基础配置
  确保事件订阅仅选择BlobCreated事件类型，使用最新的Event Grid Schema；同时确认事件订阅目标为Event Hub，且Event Hub的捕获设置未干扰事件触发逻辑。

内容的提问来源于stack exchange，提问作者arild99