test(eventhubs): add live tests for consumer groups

[Johnathan W (j7nw4r)]

Summary

Add live tests for consumer groups in azure_messaging_eventhubs. The new file covers three cases: two consumer groups read the same events from one partition, a receiver on an unknown consumer group fails, and a receiver on an unknown partition fails.

Closes #4889.

Motivation

Every live test used the $Default consumer group. The test-resources.bicep template already provisions a second group named defaultGroup, and no test used it. The with_consumer_group builder option had no live coverage, so a change that dropped the consumer group from the receiver source URL would not fail any test. Part of #4886.

Changes

• Add sdk/eventhubs/azure_messaging_eventhubs/tests/eventhubs_consumer_groups.rs with three #[recorded::test(live)] tests.
• two_consumer_groups_read_the_same_events sends five labeled events to one partition, then reads them from $Default and from defaultGroup, and asserts that both groups report the same labels in the same order and the same sequence numbers.
• receiver_on_unknown_consumer_group_fails asserts that the broker rejects the attach with amqp:not-found.
• receiver_on_unknown_partition_fails asserts that the broker rejects the attach with com.microsoft:argument-out-of-range or amqp:not-found.
• Every event carries a marker for the run, so a reader drops the traffic of other runs on the shared namespace, and a file-level lock serializes the three tests because they share partition 0.
• The change adds the test file only. It changes no source file, no Cargo.toml, and no test-resources.bicep.
• Deviation from the issue text: the issue states that opening a receiver returns an error, but open_receiver_on_partition does no network I/O and returns Ok, so the error cannot arrive there. The broker attaches the link on the first poll of stream_events(), so both error tests assert on the first item of the stream. A test that asserted on the result of open_receiver_on_partition would pass without testing anything.
• The .NET test that the issue cites for the first case, ConsumerCanReadFromMultipleConsumerGroups, declares a custom consumer group and then builds both clients with the default group, so it reads $Default twice. The test here uses two different groups instead.

Test plan

Every check below ran on the pinned 1.95 toolchain from rust-toolchain.toml.

• cargo fmt --check exits 0.
• RUSTFLAGS=-Dwarnings cargo test --no-run --package azure_messaging_eventhubs exits 0 with no warnings. CI sets RUSTFLAGS=-Dwarnings, so an unused import or an unused helper would fail the build there.
• cargo clippy --package azure_messaging_eventhubs --all-targets exits 0.
• RUSTDOCFLAGS=-Dwarnings cargo doc --package azure_messaging_eventhubs --all-features --no-deps exits 0.
• cargo test --package azure_messaging_eventhubs --test eventhubs_consumer_groups -- --test-threads=1 exits 0 and reports all three tests as ignored, which is correct for a live-gated test in a default run.
• cargo test -p azure_messaging_eventhubs -- --test-threads=1 exits 0 with 196 passed and 0 failed, so no existing test regressed.
• cspell passes on the new file with the repository configuration.

AZURE_TEST_MODE=live EVENTHUBS_HOST="<namespace>.servicebus.windows.net" EVENTHUB_NAME="<hub-name>" cargo test --package azure_messaging_eventhubs --test eventhubs_consumer_groups -- --test-threads=1 --nocapture

--test-threads=1 is required, because the three tests share partition 0.

The two expected condition sets come from the .NET mapping in Azure.Messaging.EventHubs/src/Amqp/AmqpError.cs, and they are not verified against this broker. If the broker answers with another condition, the assertion names the observed condition and its description, so the first live run reports the true value in one line.

Live validation

Every test here ran against a live Event Hubs namespace on 2026-08-20: 3 passed, 0 failed.

Command: AZURE_TEST_MODE=live cargo test --package azure_messaging_eventhubs --test eventhubs_consumer_groups -- --test-threads=1.

One defect was found and fixed by that run. The tests called the shared common::setup helper, which uses tracing_subscriber::fmt().init(). recorded::start already installs a subscriber with try_init, so init panicked and poisoned the Once around it, and every later test in the binary died at call_once. The call and the module import are gone.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
3 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.