azure_messaging_eventhubs@0.15.0

0.15.0 (Unreleased)

Features Added

• The EventProcessor now opens every partition receiver with AMQP epoch (owner level) 0 and surfaces broker-initiated displacement as the new EventHubsError::ConsumerDisconnected error kind. When a second EventProcessor instance claims a partition this instance is currently holding, the broker disconnects this instance's receiver and the consumer's stream_events() resolves with ConsumerDisconnected. This matches the behavior of EventProcessorClient in the .NET and Java Azure SDKs. Consumers should pattern-match on ErrorKind::ConsumerDisconnected to detect a stolen partition and re-acquire a client via next_partition_client().
• Added EventHubsError::ConsumerDisconnected(Option<AmqpDescribedError>) error variant.

Breaking Changes

• On the receive path, the amqp:link:stolen AMQP condition is no longer auto-retried. A receiver displaced by a higher-or-equal-epoch attacher now surfaces the error (translated to EventHubsError::ConsumerDisconnected by EventReceiver::stream_events) instead of silently re-attaching. Sender, CBS, and management operations retain the historical retry-on-stolen behavior.

Bugs Fixed

• Increased DEFAULT_PARTITION_EXPIRATION_DURATION from 10 seconds to 60 seconds. The previous default was shorter than DEFAULT_UPDATE_INTERVAL (30 seconds), so ownership records expired between load-balancing cycles. The load balancer perpetually saw current=0 for every consumer and continuously re-claimed partitions, causing widespread duplicate event processing. EventProcessorBuilder::build now rejects configurations where partition_expiration_duration <= update_interval. (#3851)
• The EventProcessor's load-balancer reconciliation now closes the underlying AMQP receiver for any partition that has been reassigned to another consumer, so the consumer's stream_events() resolves and the loop can terminate. Previously a stolen partition's client could continue to attempt receives until the broker tore down the link.

Other Changes