eventSubscriptions: endpointType "StorageQueue" is silently coerced to "WebHook" and reports Succeeded

[duuri-mollinen]

Version: floci-az 0.11.0 native (Quarkus 3.37.4)
Image: floci/floci-az:latest, sha256:6566c73b8f4b6e3ef90322c8c84a47258bb1ca13c82ea1d40027f7af11247e30

The README documents Event Grid as webhook-only ("webhook eventSubscriptions", "HTTP-only (no sidecar)"), so the missing capability is clear and expected. This issue is about how an unsupported destination type is handled: endpointType: "StorageQueue" is accepted, silently rewritten to "WebHook", and reported as Succeeded.

Reproduce

docker run -d --name floci -p 4577:4577 floci/floci-az:latest
SUB=00000000-0000-0000-0000-000000000001
B="http://127.0.0.1:4577/subscriptions/$SUB/resourceGroups/rg-probe"

# a queue to deliver into
curl -sX PUT "http://127.0.0.1:4577/devstoreaccount1-queue/q1"

curl -sX PUT -H 'content-type: application/json' -d '{"location":"westeurope"}' \
  "http://127.0.0.1:4577/subscriptions/$SUB/resourcegroups/rg-probe?api-version=2021-04-01"

curl -sX PUT -H 'content-type: application/json' -d '{"location":"westeurope"}' \
  "$B/providers/Microsoft.EventGrid/topics/t1?api-version=2022-06-15"

curl -sX PUT -H 'content-type: application/json' -d '{
  "properties": {
    "destination": {
      "endpointType": "StorageQueue",
      "properties": {
        "resourceId": "/subscriptions/'"$SUB"'/resourceGroups/rg-probe/providers/Microsoft.Storage/storageAccounts/devstoreaccount1",
        "queueName": "q1"
      }
    }
  }
}' "$B/providers/Microsoft.EventGrid/topics/t1/providers/Microsoft.EventGrid/eventSubscriptions/s1?api-version=2022-06-15"

Step 1 — the real Event Grid payload is rejected for the wrong reason

{"error":{"message":"Event subscription 's1' requires destination.properties.endpointUrl","code":"InvalidRequest"}}

endpointUrl is a WebHook destination property. A StorageQueue destination has resourceId + queueName and no endpointUrl, so the validator appears to apply the WebHook schema regardless of the declared endpointType.

Step 2 — adding endpointUrl makes it "succeed"

Retrying with endpointUrl added alongside endpointType: "StorageQueue":

{
  "name": "s1",
  "properties": {
    "provisioningState": "Succeeded",
    "destination": {
      "endpointType": "WebHook",
      "properties": { "endpointUrl": "http://localhost:4577/devstoreaccount1-queue/q1" }
    }
  }
}

StorageQueue in, WebHook out. The requested value is not echoed back and not reported as rejected.

Step 3 — publish reports success, nothing is delivered

curl -sX POST -H 'content-type: application/json' -d '[{"id":"e1","topic":"/x","subject":"s",
  "eventType":"Probe.Event","eventTime":"2026-08-25T04:20:00Z","data":{},"dataVersion":"1"}]' \
  -w '%{http_code}\n' "http://127.0.0.1:4577/t1-eventgrid/api/events"
# 200

curl -s "http://127.0.0.1:4577/devstoreaccount1-queue/q1/messages?peekonly=true"
# <QueueMessagesList/>

Expected

400 InvalidRequest at subscription creation naming the unsupported endpointType and listing what is supported — rather than substituting a different destination type. Real Event Grid rejects a destination it cannot honour.

Failing that, echoing the requested endpointType unchanged would at least make the substitution detectable; right now it is only visible by diffing the response against the request.

Why this is worth a 400

Every signal reports success — subscription Succeeded, publish 200 — while nothing is delivered and no error is recorded anywhere. The resulting symptom is an empty queue with no diagnostic, which points a developer at their own code rather than at an unimplemented destination type. A rejection at creation time makes the gap obvious in seconds.

Working correctly

Not a complaint — recording it so the scope of the report is clear:

• WebHook delivery is faithful, including the subscription validation handshake (validationCode / validationUrl) and delivery of the published event.
• Queue data plane round-trips base64 MessageText verbatim and accepts x-ms-version from 2018-03-28 through 2025-01-05.

[github-actions]

👋 Thanks for opening your first issue in floci-az!

A maintainer will triage this and add the right service label. If you included a minimal reproduction and the floci-az version, that is everything we need — no action required from you right now.

Come say hi in Slack if you want to talk it through with maintainers and other contributors. Questions about Azure behaviour, design tradeoffs, and rough proposals are all welcome there.