Event Hubs: Client Type Identifier Support

[jsquire]

Summary

When creating one of the Event Hubs client types, it can be useful for a host application to be able to uniquely identify the client instance. The Event Hubs service also supports setting the identifier of an AMQP link, which it will associate with some error messages to make it easier to correlate errors with a given client instance.

The EventProcessorClient and EventProcessor<TPartition> types support an information Identifier currently, passed in via their respective options at creation time. The remaining Event Hubs clients should be extended to follow this pattern.

Scope of Work

• The EventHubConsumerClientOptions, EventHubProducerClientOptions, and PartitionReceiverOptions should be extended with a string-based Identifier property, defaulting to null if not supplied by callers.

• The EventHubConsumerClient, EventHubProducerClient, and PartitionReceiver types should be extended with an Identifier property, mapping to the Identifer received as part of their client options. If the options do not specify an identifier, a unique one should be generated.

• When opening an AMQP link for receiving, the identifier should be used as the Target in the link settings. (example)

• When opening an AMQP link for sending, the identifier should be used as the Source in the link settings. (example)

• There should be no change to the logic when opening an AMQP RequestResponse link for management purposes; the identifier is not supported in this context.

Success Criteria

• The API changes have been informally reviewed by the .NET architects and approved.

• The client options identified in the scope have been enhanced to include an Identifier property.

• The client types identifier in the scope have been enhanced to accept the identifier from the options, expose it via an Identifier property, and use it with the AmqpConnectionScope when creating links.

• The AmqpConnectionScope has been updated to apply the identifier specified at construction in the Target or Source settings when opening links. The existing logic for populating the link name should not change.

• The tests necessary for ensuring the feature works as intended have been created or adjusted and pass reliably.

• Existing tests continue to produce deterministic results and pass reliably.

[jsquire]

Fixed by #22614