Events publishing but not matching to the event subscription

Hi @Lucresse Pearle ,
Compare one working and one failing event Compare the complete event payload generated by:

• Manual file upload, which delivers successfully.
• SAS-based upload, which doesn't match/deliver.

Pay particular attention to type, subject, and any fields used by advanced subscription filters, since Event Grid namespace subscriptions can filter on event types, subject prefix/suffix, and advanced fields.

1. Check all subscription filters Even if eventType and subject look the same, verify whether any advanced filtering exists and whether the corresponding event field/value differs between the working and failing events.
2. Verify the SAS scope Confirm that the SAS token is scoped to the expected Event Grid namespace/topic. Event Grid SAS tokens can be scoped at namespace, namespace-topic, or event-subscription level.

Confirm whether this is matching or delivery If the event doesn't match the subscription, focus on payload/filter differences. If it matches but isn't reaching the destination, investigate the event handler/delivery path separately. Event subscriptions determine which topic events are sent to the configured endpoint.

Hi @Lucresse Pearle ,

you are trying to find out why events from uploads that use a SAS token are published to the Event Grid namespace topic but do not match the subscription, while manual uploads to the same path match and are delivered. Subject, event type, path, suffix, and casing are identical in both payloads.

Compare the data section of both events

Subject and event type are covered by your comparison, and path, suffix, and casing are part of the subject. The data object of the event has not been compared yet. If these are Blob Storage events forwarded to the namespace topic, each event also carries a data object whose values depend on the REST operation the uploading client called. The SAS token itself is not a matching criterion, but the client that uses it can call a different operation than the portal does. The Blob Storage event schema documents three fields that can differ while the subject stays identical:

• data.api names the operation that triggered the event. With the Blob REST API, BlobCreated is raised for PutBlob, PutBlockList, and CopyBlob. On an account with hierarchical namespace enabled, a client that uses the Data Lake Storage Gen2 API produces CreateFile and FlushWithClose instead, and the documented CreateFile example has a contentLength of 0.
• data.contentType is the content type stored on the blob. Per Put Blob, the default is application/octet-stream when no content type is specified. A client can set the stored value through the Content-Type header or the x-ms-blob-content-type header, so the value depends on what the uploading tool sends.
• data.contentLength is the blob size in bytes.

Check for advanced filters on the namespace subscription

You mention that the filters were checked and have not changed. Unchanged filters can still reject events whose data differs, so the first question is whether the subscription has any advanced filters on keys inside data. If it does, two documented behaviors apply:

• If the event does not contain the filter key, most operators, StringIn included, evaluate to not matched.
• String comparisons in advanced filters are not case-sensitive, so casing in data values cannot explain the mismatch.

A StringIn filter on data.api listing PutBlob and PutBlockList does not match FlushWithClose, although all three operations raise Microsoft.Storage.BlobCreated. The schema documentation recommends filtering on FlushWithClose for Data Lake Storage Gen2, so a filter list written for one client can lack the operation that another client uses. The same applies to a filter on data.contentType or a minimum data.contentLength. If the subscription has no advanced filters, this explanation does not apply.

Check the matching metrics

The namespace exposes Unmatched Events, counted for the whole topic, and Matched Events, counted per subscription. If Unmatched Events increases during a test window with only SAS uploads while Matched Events stays flat for the affected subscription, the events reach the topic and no subscription matches them, which rules out a delivery failure at the destination. The metrics do not show whether a filter or a service-side problem causes the mismatch. Advanced filters can also reference CloudEvents attributes such as source or extension attributes, so the comparison has to cover every key the filters use, inside and outside data. If both events satisfy all configured filter criteria and only one of them matches, an Azure Support case is the next step for the service-side matching behavior.

Could you share the subscription's full filter definition, advanced filters included, together with one complete matching and one complete non-matching event?

References

• Azure Blob Storage as an Event Grid source
• Event filters for subscriptions to Azure Event Grid namespace topics
• Put Blob (REST API)
• Supported metrics for Microsoft.EventGrid/namespaces

Drafted with help from Claude, disclosed per the Q&A AI usage policy. Documented: event fields, filter behavior, and metrics, checked against the Learn pages listed above. Not reproduced: that the events are forwarded Blob Storage events and that the two upload paths differ in the data section.

I have compared:

• subject
• event type
• container path / blob path
• filename suffix
• casing

and they are all identical.