Azure Event Grid System Topic not reacting to new blob upload

I have had a big problem with azure event grid system topics not responding to uploaded blobs from azure function apps or azure logic apps. When i manually upload file (even same file) it works

There is a big bug in blob storage and event grid, where blob storage will allow you to upload to a storage with a leading / in blob path, this will result in event grid system topic not responding to the event, since it had https://storagename.blob.core.windows.net/container//folder/folder/file.txt you might make it work if you add a // in your subject filters

But in my opinion blob storage should not allow you to upload the file when path is not valid, as it is in this case

In my understanding Event Grid System Topics is reacting to Log Analytics Workspace(or just plain logs) putBlob and you subject filter, but i filter does not have //, then it will not take any action as it didn't match

I spent a week debugging and had multiple teams meeting with multiple people from azure support both Event Grid team and Storage Blob team, none of them spotted the problem with double forward slash, and even when I found the bug and told them, then will not acknowledge that its a bug and that they need to get it fixed. Solution is to remove your leading slash in you code

I have created a subscription (name is abc) on the storage account (rk2018ebstg) with your filter, see the following screen snippet of my Azure Event Grid Tester tool:

then I have uploaded a blob file using the REST API Put request:

https://rk2018ebstg.blob.core.windows.net/container/folder/folder/2024-04-21T00:16:40.txt?sp=racwd&st=2024-04-21T00:16:40Z&se=2034-04-21T08:16:40Z&sv=2022-11-02&sr=c&sig=****

The following screen snippet shows a received event message on the storage topic:

As you can see the above screens, the AEG is reacting correctly included its filtering.

Your comments related to the '< no name >' in the path of the blob (e.g. multiple '/') is not a bug, it is based on the design, see here, so in other words, the '< no name >' dictionary is a valid dictionary name.

I do recommend using an advanced filtering in the AEG subscription, see the following example:

"advancedFilters":[
      {
        "values":[
          "/containers/container/blobs//folder/folder/",
          "/containers/container/blobs/folder/folder/"
        ],
        "operatorType":"StringContains",
        "key":"subject"
      }
    ]