[BUG] Event Hubs: no CBS responder is started, so Azure SDKs cannot authorize over AMQP

[deyanp]

Event Hubs namespaces start an Artemis broker with nothing answering $cbs. The
put-token every Azure SDK sends before its first link gets a reply with no
status-code, and the client fails. Service Bus namespaces get a responder and do not
have this problem.

Both brokers start; only one gets a responder:

INFO [io.flo.az.ser.eve.EventHubNamespaceManager]  Starting Artemis broker for Event Hubs namespace 'emulatorNs1' (plain:5,672, TLS:5,671)
INFO [io.flo.az.ser.ser.ServiceBusNamespaceManager] Starting Artemis broker for Service Bus namespace 'default' (plain:5,673, TLS:5,674)
INFO [io.flo.az.ser.ser.ServiceBusCbsResponder]     CBS responder started for 172.17.0.13:5,672

Repro

docker run -d --name floci-az \
  -e FLOCI_AZ_SERVICES_EVENT_HUB_MOCKED=false \
  -e FLOCI_AZ_SERVICES_SERVICE_BUS_MOCKED=false \
  -p 4577:4577 -v /var/run/docker.sock:/var/run/docker.sock \
  floci/floci-az:latest

curl -s -X PUT http://localhost:4577/devstoreaccount1-eventhub/namespaces/emulatorNs1 \
  -H 'Content-Type: application/json' -d '{}'

curl -s -X PUT http://localhost:4577/devstoreaccount1-servicebus/test-hub \
  -H 'Content-Type: application/atom+xml' \
  -d '<entry xmlns="http://www.w3.org/2005/Atom"><content type="application/xml"><QueueDescription xmlns="http://schemas.microsoft.com/netservices/2010/10/servicebus/connect"/></content></entry>'

(Do not publish 5672/5673 on the floci-az container — the sidecars bind those host
ports themselves.)

Client — Rust, azure_messaging_eventhubs 0.15:

use std::sync::Arc;
use azure_core::credentials::{AccessToken, TokenCredential, TokenRequestOptions};
use azure_messaging_eventhubs::ProducerClient;

#[derive(Debug)]
struct AnyToken; // floci accepts any token

#[async_trait::async_trait]
impl TokenCredential for AnyToken {
    async fn get_token(&self, _: &[&str], _: Option<TokenRequestOptions<'_>>)
        -> azure_core::Result<AccessToken> {
        Ok(AccessToken::new("any-token",
            azure_core::time::OffsetDateTime::now_utc() + azure_core::time::Duration::hours(1)))
    }
}

#[tokio::main]
async fn main() {
    let endpoint = std::env::var("ENDPOINT").unwrap_or("amqp://localhost:5672".into());
    let producer = ProducerClient::builder()
        .with_custom_endpoint(endpoint)
        .open("emulatorns1.servicebus.windows.net", "test-hub", Arc::new(AnyToken))
        .await.unwrap();
    // first call that authorizes a path
    println!("{:?}", producer.create_batch(None).await.err());
}

Observed

ENDPOINT=amqp://localhost:5672   # Event Hubs
create_batch FAILED: Transport Implementation Error: StatusCode is nor found

ENDPOINT=amqp://localhost:5673   # Service Bus, same client
create_batch FAILED: Management API returned status code: 200 (OK)

Expected: create_batch succeeds, as against a real namespace.

Analysis

The two errors give the diagnosis:

• 5672 — no status-code in the reply at all: nothing implements $cbs. Artemis
  auto-creates the address and reply-to node, but there are no CBS semantics behind it.
• 5673 — a status-code is present, so the responder answered. It replies 200;
  CBS put-token must return 202. fe2o3-amqp-cbs hard-codes
  const STATUS_CODE: u16 = 202 (put_token.rs:93) and rejects the 200.

Suggested fix

1. Start a CBS responder for Event Hubs namespaces. ServiceBusCbsResponder already
   exists and is started by ServiceBusNamespaceManager; EventHubNamespaceManager
   starts its Artemis without one.
2. Reply 202 rather than 200 to put-token — this also affects Service Bus clients on
   strict CBS implementations.

Follow-on gaps

CBS alone will not complete a round-trip. The next two calls are:

• sender.max_message_size(), required by create_batch — same defect as [BUG] Service Bus: Java SDK cannot send over AMQP in broker mode — Artemis omits max-message-size on ATTACH, azure-core-amqp treats it as 0 #128
  (ATTACH omits max-message-size), already fixed for Service Bus.
• get_eventhub_properties() — the Event Hubs $management READ used to enumerate
  partitions before receiving; needs an Event-Hubs-specific management responder.

Happy to test any of these.

Environment

floci-az	0.11.0 (sha256:6566c73b8f4b6e3ef90322c8c84a47258bb1ca13c82ea1d40027f7af11247e30, arm64)
Artemis	apache/activemq-artemis:2.44.0
Docker	28.4.0, Darwin arm64
Client	azure_messaging_eventhubs 0.15.0, azure_core_amqp 1.0.0, fe2o3-amqp-cbs 0.14.0

Event Hubs AMQP landed in #17 and appears not to have had the SDK-compat work Service
Bus has since received (#128, #159, #170). This looks like its counterpart.

[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.

[thomhurst]

Reconfirmed on floci-az 0.12.0 while adding the Testcontainers for .NET module compatibility suite.

Environment:

• floci-az 0.12.0, digest sha256:0c673d49bb75b502ea0750f1c1347777483ffc33945539e1d9254438cb441a03
• Azure.Messaging.EventHubs 5.12.2
• Docker Desktop, Linux containers
• floci-az running as a container with the Docker socket mounted
• FLOCI_AZ_SERVICES_EVENT_HUB_ENABLED=true
• FLOCI_AZ_SERVICES_EVENT_HUB_MOCKED=false

The Artemis sidecar starts, but the .NET SDK AMQP data-plane cases fail with connection resets. This matches the 0.12.0 application.yml comment that real Event Hubs currently fails 6/6 compatibility tests.

I am therefore keeping Event Hubs disabled by default in the Testcontainers module and covering namespace management in mocked mode until this issue is fixed. Service Bus through the same topology passes real Azure.Messaging.ServiceBus send/receive, which helps isolate this to Event Hubs protocol compatibility rather than Docker socket or sidecar routing.